linux-kernel - Re: Multiple potential races on vma->vm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150924172609.GA29842@redhat.com>
Date:	Thu, 24 Sep 2015 19:26:09 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Sasha Levin <sasha.levin@...cle.com>
Cc:	Hugh Dickins <hughd@...gle.com>,
	"Kirill A. Shutemov" <kirill@...temov.name>,
	Andrey Konovalov <andreyknvl@...gle.com>,
	Rik van Riel <riel@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Dmitry Vyukov <dvyukov@...gle.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, Vlastimil Babka <vbabka@...e.cz>
Subject: Re: Multiple potential races on vma->vm_flags

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,

> >>    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?

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

> I hope the information above helped, please let me know if it didn't and you
> need anything else.

Thanks a lot, it does help, but I am still confused.


Looks like, "function+offset" is more useful than the line numbers,
at least we could look at mm/memory.s.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/