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)
Attachment:
pgp4Aq93nmQcj.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
