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)
pgphJuVx5TEcc.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
