[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aEb3od8YQTvDQu4q@x1.local>
Date: Mon, 9 Jun 2025 11:02:57 -0400
From: Peter Xu <peterx@...hat.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Tal Zussman <tz2294@...umbia.edu>,
"Jason A. Donenfeld" <Jason@...c4.com>,
David Hildenbrand <david@...hat.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
Andrea Arcangeli <aarcange@...hat.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v2 1/4] userfaultfd: correctly prevent registering
VM_DROPPABLE regions
On Sat, Jun 07, 2025 at 03:04:38PM -0700, Andrew Morton wrote:
> On Sat, 07 Jun 2025 02:40:00 -0400 Tal Zussman <tz2294@...umbia.edu> wrote:
>
> > vma_can_userfault() masks off non-userfaultfd VM flags from vm_flags.
> > The vm_flags & VM_DROPPABLE test will then always be false, incorrectly
> > allowing VM_DROPPABLE regions to be registered with userfaultfd.
> >
> > Additionally, vm_flags is not guaranteed to correspond to the actual
> > VMA's flags. Fix this test by checking the VMA's flags directly.
>
> Wondering if we should backport this. afaict we don't know the
> userspace impact of this because nobody has tried it!
Yes that's fair question. Per my limited understanding of MAP_DROPPABLE
(even if as a generic flag), I'd be surprised if someone tries to enable
userfaultfd on it, being succeeded or not.. or requiring that to properly
fail on any stable branches. AFAIU that's the only possible effect we can
expect from a backport.
IMHO for this case we can avoid backporting until anyone requested with an
explicit use case.
Thanks,
--
Peter Xu
Powered by blists - more mailing lists