Re: [BUG] mm: mremap merge clears RWP state from an untouched neighbor

[Mike Rapoport]

(adding Kiryl)

On Tue, Oct 20, 2026 at 11:07:48AM +0000, shaos wrote:
> Hello,
> 
> An adjacent mremap() can remove userfaultfd RWP handling from a
> neighboring VMA that was not moved. The moved VMA and the existing
> neighbor use the same userfaultfd context, and UFFD_FEATURE_EVENT_REMAP
> is not negotiated. When the destination merges into the neighbor,
> mremap_userfaultfd_prep() resets the context on the expanded VMA,
> including the neighbor.
> 
> The neighbor's PTE remains PAGE_NONE with _PAGE_UFFD, but the VMA loses
> VM_UFFD_RWP. A read that delivered UFFD_PAGEFAULT_FLAG_RWP before the
> move then completes without an event. The same-mm PoC reproduces this on
> two fresh boots. No-move and nonadjacent-move controls retain the RWP
> event.
> 
> HEAD commit:    24a19b953e2a3d0ea5a8c4951a0ab8f32720c907
> source version: Linux 7.3.0-rc7
> architecture:   x86-64
> compiler:       gcc 11.4.0, GNU ld 2.38
> QEMU:           6.2.0
> 
> console output: https://gist.githubusercontent.com/shaos26/3b44971d9385a0cd18cfbf2e9bd730c6/raw/368568c2dd47417b54a957c8d9cc09f77f28b236/console-output.txt
> kernel config: https://gist.githubusercontent.com/shaos26/3b44971d9385a0cd18cfbf2e9bd730c6/raw/4989bc843fa61b5eaaaa53422238ec39e4356b70/kernel-config.txt
> reproducer: https://gist.githubusercontent.com/shaos26/3b44971d9385a0cd18cfbf2e9bd730c6/raw/109dc86c28debcaca07aedb2d450ed1e95ae5edf/poc.c
> 
> Build the kernel from the revision above with the attached config. Build
> poc.c statically with pthread support and place it at /init in a minimal
> initramfs. The positive run and controls use:
> 
>     timeout 180 qemu-system-x86_64 -accel tcg,thread=multi -cpu max \
>         -m 1024 -smp 2 -machine q35 -nodefaults \
>         -kernel build/arch/x86/boot/bzImage -initrd initramfs.cpio.gz \
>         -append "console=ttyS0 panic=-1 oops=panic loglevel=7 rwp.mode=positive" \
>         -display none -serial stdio -monitor none -no-reboot
> 
> Use rwp.mode=no_move and rwp.mode=nonadjacent for the controls. The
> positive oracle is PRECHECK fault flags=0x8 followed by POST no_event
> value=0x41 and RESULT=RWP_NEIGHBOR_ESCAPE_CONFIRMED. This is a
> userfaultfd tracking defect; no privilege escalation or cross-process
> access is demonstrated. I checked upstream master f47d223627f8; the
> relevant mremap/userfaultfd logic is unchanged there, but runtime
> validation was on v7.3-rc7.
> 
> Thanks,
> 
> shaos
> 

-- 
Sincerely yours,
Mike.