kernel BUG at lib/assoc_array.c:LINE!
dhowells at redhat.com
Mon Mar 2 08:28:52 UTC 2020
Jarkko Sakkinen <jarkko.sakkinen at linux.intel.com> wrote:
> The arguments for request_key_and_link() are fairly constrained:
> type == &key_type_dns_resolver
> description == "afsdb:<cell name>"
> domain_tag == net->key_domain
> callout_info == "srv=1"
> callout_len == 5
> aux == NULL
> dest_keyring == NULL
> flags == KEY_ALLOC_IN_QUOTA
> (manually resolved)
> The only obvious moving part I see is the key type implementatio i.e.
It shouldn't matter what the payload of the key is going to be, but it might
matter what the cell name is. Looking in the log, I see this:
mount(&(0x7f0000000000)=ANY=[@ANYBLOB="25dc545df1e34ab2e26e2f5034c85b3a"], &(0x7f0000000140)='./file0\x00', &(0x7f0000000180)='afs\x00', 0x0, 0x0)
is the source, i.e.:
This is in the form "[%#][<cellname>:]<volumename>", which comports with the
[ 621.627412][ T6728] kAFS: unable to lookup cell '?T]??J??n/P4?['
This is a bit odd, since the version allegedly being tested includes a patch
to prohibit AFS cell names that contain unprintable chars. It should error
out in afs_alloc_cell(), way before it tries to do a DNS lookup.
More information about the Linux-security-module-archive