kernel BUG at lib/assoc_array.c:LINE!

David Howells dhowells at
Mon Mar 2 08:28:52 UTC 2020

Jarkko Sakkinen <jarkko.sakkinen at> 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
> (manually resolved)
> The only obvious moving part I see is the key type implementatio i.e.
> net/dns_resolver/dns_key.c.

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 mailing list