Possible Bug

[Valdis.Kletnieks at vt.edu]

On Thu, 31 Mar 2016 09:30:01 -0700, John Johansen said:

> hrmm, the only thing apparmor is doing in this kernel here is a kzalloc and
> assigning it to f_security, expanding out the aa_alloc_file_context
> abstraction (which should probably just be dropped) we get.
>
>   	file->f_security =  kzalloc(sizeof(struct aa_file_cxt), GFP_KERNEL);
> 	if (!file->f_security)
> 		return -ENOMEM;
> 	return 0;
>
> So unless we are getting a NULL for the file I don't see how apparmor can be
> causing the NULL pointer dereference

Now here's the odd part - just before that, we have:

        f->f_cred = get_cred(cred);
        error = security_file_alloc(f);

so if f-> was NULL, we should have exploded just *before* the security_file_alloc()
call.

>> [952620.397309] IP: [<ffffffff811e636b>] kmem_cache_alloc_trace+0x7b/0x1e0

Aha.  Smoking gun - I should have spotted this before.  f-> isn't the null
pointer - it's exploding trying to alloc a slab.  You're right, John - it looks
like somebody did the fandango all over the memory allocator.

Roger - can you find out if this kernel was using SLAB, SLOB, or SLUB as
the allocator?  And is KASAN enabled or not? (I see a kasan_kmalloc() lurking
in slab.h)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160331/6d61410e/attachment-0001.bin