On Thu, Mar 31, 2016 at 3:22 PM, <Valdis.Kletnieks@vt.edu> wrote:
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)
I had a look inside the .config I used to compile this kernel. I think I found the information you're looking for. # CONFIG_KASAN is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set