linux-kernel - Re: [PATCH v3 8/8] x86, mm, gup: prevent get_page() race with munmap in paravirt guest

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: <20191216134725.GE2827@hirez.programming.kicks-ass.net>
Date:   Mon, 16 Dec 2019 14:47:25 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:     Ajay Kaher <akaher@...are.com>, gregkh@...uxfoundation.org,
        stable@...r.kernel.org, torvalds@...ux-foundation.org,
        punit.agrawal@....com, akpm@...ux-foundation.org,
        kirill.shutemov@...ux.intel.com, willy@...radead.org,
        will.deacon@....com, mszeredi@...hat.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, srivatsab@...are.com,
        srivatsa@...il.mit.edu, amakhalov@...are.com, srinidhir@...are.com,
        bvikas@...are.com, anishs@...are.com, vsirnapalli@...are.com,
        srostedt@...are.com, Vlastimil Babka <vbabka@...e.cz>,
        Oscar Salvador <osalvador@...e.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Juergen Gross <jgross@...e.com>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH v3 8/8] x86, mm, gup: prevent get_page() race with munmap
 in paravirt guest

On Mon, Dec 16, 2019 at 02:30:44PM +0100, Vitaly Kuznetsov wrote:
> Peter Zijlstra <peterz@...radead.org> writes:
> 
> > On Tue, Dec 17, 2019 at 02:15:48AM +0530, Ajay Kaher wrote:
> >> From: Vlastimil Babka <vbabka@...e.cz>
> >> 
> >> The x86 version of get_user_pages_fast() relies on disabled interrupts to
> >> synchronize gup_pte_range() between gup_get_pte(ptep); and get_page() against
> >> a parallel munmap. The munmap side nulls the pte, then flushes TLBs, then
> >> releases the page. As TLB flush is done synchronously via IPI disabling
> >> interrupts blocks the page release, and get_page(), which assumes existing
> >> reference on page, is thus safe.
> >> However when TLB flush is done by a hypercall, e.g. in a Xen PV guest, there is
> >> no blocking thanks to disabled interrupts, and get_page() can succeed on a page
> >> that was already freed or even reused.
> >> 
> >> We have recently seen this happen with our 4.4 and 4.12 based kernels, with
> >> userspace (java) that exits a thread, where mm_release() performs a futex_wake()
> >> on tsk->clear_child_tid, and another thread in parallel unmaps the page where
> >> tsk->clear_child_tid points to. The spurious get_page() succeeds, but futex code
> >> immediately releases the page again, while it's already on a freelist. Symptoms
> >> include a bad page state warning, general protection faults acessing a poisoned
> >> list prev/next pointer in the freelist, or free page pcplists of two cpus joined
> >> together in a single list. Oscar has also reproduced this scenario, with a
> >> patch inserting delays before the get_page() to make the race window larger.
> >> 
> >> Fix this by removing the dependency on TLB flush interrupts the same way as the
> >
> > This is suppsed to be fixed by:
> >
> > arch/x86/Kconfig:       select HAVE_RCU_TABLE_FREE              if PARAVIRT
> >
> 
> Yes,
> 
> but HAVE_RCU_TABLE_FREE was enabled on x86 only in 4.14:
> 
> commit 9e52fc2b50de3a1c08b44f94c610fbe998c0031a
> Author: Vitaly Kuznetsov <vkuznets@...hat.com>
> Date:   Mon Aug 28 10:22:51 2017 +0200
> 
>     x86/mm: Enable RCU based page table freeing (CONFIG_HAVE_RCU_TABLE_FREE=y)
> 
> and, if I understood correctly, Ajay is suggesting the patch for older
> stable kernels (4.9 and 4.4 I would guess).

It wasn't at all clear this was targeted at old kernels (I only got this
one patch).

And why can't those necro kernels do backports of the upstream solution?