On Thu, Jun 5, 2025 at 5:06 PM David Hildenbrand <david@xxxxxxxxxx> wrote: > > 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. Yes, this is exactly what I was thinking. Or (less likely) a child process that inherits a uffd from its parent can then mess with memory the parent registers with a different uffd after the fork. > -- > Cheers, > > David / dhildenb >
