[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjSeNSeT44BZpZoQu+nFjDHVCy2t0kKMjkXnBfLOaPGLg@mail.gmail.com>
Date: Mon, 21 Dec 2020 15:13:14 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Peter Xu <peterx@...hat.com>
Cc: Nadav Amit <nadav.amit@...il.com>, Yu Zhao <yuzhao@...gle.com>,
Andrea Arcangeli <aarcange@...hat.com>,
linux-mm <linux-mm@...ck.org>,
lkml <linux-kernel@...r.kernel.org>,
Pavel Emelyanov <xemul@...nvz.org>,
Mike Kravetz <mike.kravetz@...cle.com>,
Mike Rapoport <rppt@...ux.vnet.ibm.com>,
stable <stable@...r.kernel.org>,
Minchan Kim <minchan@...nel.org>,
Andy Lutomirski <luto@...nel.org>,
Will Deacon <will@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
On Mon, Dec 21, 2020 at 1:55 PM Peter Xu <peterx@...hat.com> wrote:
>
> Frankly speaking I don't know why it's always safe to do data copy without the
> pgtable lock in wp_page_copy(), since I don't know what guaranteed us from data
> changing on the original page due to any reason.
So the reason it should be safe is that
(a) the pte is write-protected
(b) we're clearly not a shared mapping, so that if anybody else
writes to the page in another mapping, that's irrelevant (think of it
as "page copy happened earlier")
(c) before we install the copied page, we check that nothing changed
our initial assumption in (a).
And the problem is that userfaultfd basically can cause that (c) phase to fail.
Linus
Powered by blists - more mailing lists