linux-kernel - Re: [PATCH v1] mm: fix PageAnonExclusive clearing racing with concurrent RCU GUP-fast

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] [day] [month] [year] [list]

Date:   Fri, 2 Sep 2022 08:49:19 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        stable@...r.kernel.org, Jason Gunthorpe <jgg@...dia.com>,
        John Hubbard <jhubbard@...dia.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Hugh Dickins <hughd@...gle.com>, Peter Xu <peterx@...hat.com>,
        Alistair Popple <apopple@...dia.com>,
        Nadav Amit <namit@...are.com>, Yang Shi <shy828301@...il.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Michal Hocko <mhocko@...nel.org>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Andrea Parri <parri.andrea@...il.com>,
        Will Deacon <will@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Christoph von Recklinghausen <crecklin@...hat.com>,
        Don Dutile <ddutile@...hat.com>
Subject: Re: [PATCH v1] mm: fix PageAnonExclusive clearing racing with
 concurrent RCU GUP-fast

On 02.09.22 00:35, Andrew Morton wrote:
> On Thu,  1 Sep 2022 10:35:59 +0200 David Hildenbrand <david@...hat.com> wrote:
> 
>> The possible issues due to reordering are of theoretical nature so far
>> and attempts to reproduce the race failed.
>>
>> Especially the "no PTE change" case isn't the common case, because we'd
>> need an exclusive anonymous page that's mapped R/O and the PTE is clean
>> in KSM code -- and using KSM with page pinning isn't extremely common.
>> Further, the clear+TLB flush we used for now implies a memory barrier.
>> So the problematic missing part should be the missing memory barrier
>> after pinning but before checking if the PTE changed.
> 
> Obscure bug, large and tricky patch.  Is a -stable backport really
> justifiable?

Fair question, was asking myself the same. As you're wondering about the
same, I don't think so. Let's drop it.

Out of the CONFIG_HAVE_FAST_GUP supporting architectures primarily only
the 32bit architectures can even lose the PageAnonExclusive during
swapout (until we make them all preserve it in the swp PTE), the other
ones already support preserve it.

So unless fork() would be involved at the wrong time as well,  x86-64,
s390x, aarch64, ppc64 book3s ... wouldn't even have a real issue with
this race.

(note that the actual code changes are small -- but yes, I think
linux-stable rules always consider the full patch LOC)

-- 
Thanks,

David / dhildenb