On Thu, Mar 31, 2016 at 3:22 PM, <Valdis.Kletnieks@xxxxxx> 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
