Possible Bug

[Roger H Newell]

On Thu, Mar 31, 2016 at 3:22 PM,  <Valdis.Kletnieks at 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