Re: Multiple potential races on vma->vm_flags

[Andrey Ryabinin <ryabinin.a.a@gmail.com>]

2015-09-24 20:26 GMT+03:00 Oleg Nesterov <oleg@redhat.com>:
> On 09/24, Sasha Levin wrote:
>>
>> On 09/24/2015 09:11 AM, Oleg Nesterov wrote:
>> >
>> > Well, I know absolutely nothing about kasan, to the point I can't even
>> > unserstand where does this message come from. grep didn't help. But this
>> > doesn't matter...
>>
>> The reason behind this message is that NULL ptr derefs when using kasan are
>> manifested as GFPs. This is because in order to validate an access to a given
>> memory address kasan would check (shadow_base + (mem_offset >> 3)), so in the case of
>> a NULL it would try to access shadow_base + 0, which would GFP.
>
> OK, so this just means the kernele derefs the NULL pointer,
>
>> I'm running -next + Kirill's THP patchset.
>>
>> >     struct mm_struct *mm = vma->vm_mm;
>>
>> void unmap_vmas(struct mmu_gather *tlb,
>>                 struct vm_area_struct *vma, unsigned long start_addr,
>>                 unsigned long end_addr)
>> {
>>         struct mm_struct *mm = vma->vm_mm;
>>
>>         mmu_notifier_invalidate_range_start(mm, start_addr, end_addr);
>>         for ( ; vma && vma->vm_start < end_addr; vma = vma->vm_next)
>>                 unmap_single_vma(tlb, vma, start_addr, end_addr, NULL); <--- this
>>         mmu_notifier_invalidate_range_end(mm, start_addr, end_addr);
>> }
>
> And I do not see any dereference at this line,
>

I noticed, that addr2line sometimes doesn't work reliably on
compiler-instrumented code.
I've seen couple times that it points to the next line of code.


>> >>    0:   08 80 3c 02 00 0f       or     %al,0xf00023c(%rax)
>> >>    6:   85 22                   test   %esp,(%rdx)
>> >>    8:   01 00                   add    %eax,(%rax)
>> >>    a:   00 48 8b                add    %cl,-0x75(%rax)
>> >>    d:   43                      rex.XB
>> >>    e:   40                      rex
>> >>    f:   48 8d b8 c8 04 00 00    lea    0x4c8(%rax),%rdi
>> >>   16:   48 89 45 d0             mov    %rax,-0x30(%rbp)
>> >>   1a:   48 b8 00 00 00 00 00    movabs $0xdffffc0000000000,%rax
>> >>   21:   fc ff df
>> >>   24:   48 89 fa                mov    %rdi,%rdx
>> >>   27:   48 c1 ea 03             shr    $0x3,%rdx
>> >>   2b:*  80 3c 02 00             cmpb   $0x0,(%rdx,%rax,1)               <-- trapping instruction
>> >>   2f:   0f 85 ee 00 00 00       jne    0x123
>> >>   35:   48 8b 45 d0             mov    -0x30(%rbp),%rax
>> >>   39:   48 83 b8 c8 04 00 00    cmpq   $0x0,0x4c8(%rax)
>> >>   40:   00
>> >
>> > And I do not see anything similar in "objdump -d". So could you at least
>> > show mm/memory.c:1337 in your tree?
>> >
>> > Hmm. movabs $0xdffffc0000000000,%rax above looks suspicious, this looks
>> > like kasan_mem_to_shadow(). So perhaps this code was generated by kasan?
>> > (I can't check, my gcc is very old). Or what?
>>
>> This is indeed kasan code. 0xdffffc0000000000 is the shadow base, and you see
>> kasan trying to access shadow base + (ptr >> 3), which is why we get GFP.
>
> and thus this asm can't help, right?
>

I think it can.

> So how can we figure out where exactly the kernel hits NULL ? And what
> exactly it tries to dereference?

So we tried to dereference 0x4c8.  That 0x4c8 is probably offset in some struct.
The only big struct here is mm_struct.
So I think that we tried to derefernce null mm, and this asm:
         > cmpq   $0x0,0x4c8(%rax)

is likely from inlined mm_has_notifiers():
    static inline int mm_has_notifiers(struct mm_struct *mm)
    {
             return unlikely(mm->mmu_notifier_mm);
    }


Sasha, could you confirm that in your kernel mmu_notifier_mm field has
0x4c8 offset?
I would use gdb for that:
gdb vmlinux
(gdb) p/x &(((struct mm_struct*)0)->mmu_notifier_mm)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>