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

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

[shaos]

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

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

[Lorenzo Stoakes (ARM)]

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 for the report. I think restricting merges for UFFD seems a sensible
solution, will put something together.

It doesn't _seem_ to be addressed by anything we have recently, either.

(Small nit on email, please try to line-wrap to 75 chars, makes it harder to
read mail on the antiquated systems we use :P)

--
Cheers, Lorenzo

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.

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

[Lorenzo Stoakes (ARM)]

On Tue, Oct 20, 2026 at 07:34:19PM +0300, Mike Rapoport wrote:
> (adding Kiryl)

Fix patch is at https://lore.kernel.org/linux-mm/20261020-uffd-remap-fix-v1-1-0f34fc181f0a@kernel.org/

--
Cheers, Lorenzo