linux-kernel - Re: [PATCH 2/3] userfaultfd: prevent unregistering VMAs through a different userfaultfd

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: <0a1dab1c-80d2-436f-857f-734d95939aec@redhat.com>
Date: Thu, 5 Jun 2025 23:06:38 +0200
From: David Hildenbrand <david@...hat.com>
To: Peter Xu <peterx@...hat.com>
Cc: Tal Zussman <tz2294@...umbia.edu>,
 Andrew Morton <akpm@...ux-foundation.org>,
 "Jason A. Donenfeld" <Jason@...c4.com>,
 Alexander Viro <viro@...iv.linux.org.uk>,
 Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
 Pavel Emelyanov <xemul@...allels.com>, Andrea Arcangeli
 <aarcange@...hat.com>, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 2/3] userfaultfd: prevent unregistering VMAs through a
 different userfaultfd

On 04.06.25 17:09, Peter Xu wrote:
> On Wed, Jun 04, 2025 at 03:23:38PM +0200, David Hildenbrand wrote:
>> On 04.06.25 00:14, Tal Zussman wrote:
>>> Currently, a VMA registered with a uffd can be unregistered through a
>>> different uffd asssociated with the same mm_struct.
>>>
>>> Change this behavior to be stricter by requiring VMAs to be unregistered
>>> through the same uffd they were registered with.
>>>
>>> While at it, correct the comment for the no userfaultfd case. This seems
>>> to be a copy-paste artifact from the analagous userfaultfd_register()
>>> check.
>>
>> I consider it a BUG that should be fixed. Hoping Peter can share his
>> opinion.
> 
> Agree it smells like unintentional, it's just that the man page indeed
> didn't mention what would happen if the userfaultfd isn't the one got
> registered but only requesting them to be "compatible".
> 
> DESCRIPTION
>         Unregister a memory address range from userfaultfd.  The pages in
>         the range must be “compatible” (see UFFDIO_REGISTER(2const)).
> 
> So it sounds still possible if we have existing userapp creating multiple
> userfaultfds (for example, for scalability reasons on using multiple
> queues) to manage its own mm address space, one uffd in charge of a portion
> of VMAs, then it can randomly take one userfaultfd to do unregistrations.
> Such might break.

Not sure if relevant, but consider the following:

an app being controlled by another process using userfaultfd.

The app itself can "escape" uffd control of the other process by simply 
creating a userfaultfd and unregistering VMAs.

-- 
Cheers,

David / dhildenb