lkml.org 
[lkml]   [2015]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Multiple potential races on vma->vm_flags
On 09/24, Andrey Ryabinin wrote:
>
> 2015-09-24 20:26 GMT+03:00 Oleg Nesterov <oleg@redhat.com>:
> > On 09/24, Sasha Levin wrote:
> >>
> >> 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.

Yes, I know that we can't trust it. That is why I think (at least in
this particular case) function+offset would be more helpful. And we
need more asm probably.

> >> >> 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);
> }

Looks reasonable... Thanks.

I was going to say that this is impossible because the caller should have
crashed if ->mm == NULL. But unmap_vmas() uses mm = vma->vm_mm, so it looks
like this vma or mm->mmap was corrupted...

Oleg.



\
 
 \ /
  Last update: 2015-09-25 15:01    [W:0.054 / U:5.496 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site