CVE-2025-39775

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/mremap: fix WARN with uffd that has remap events disabled<br /> <br /> Registering userfaultd on a VMA that spans at least one PMD and then<br /> mremap()&amp;#39;ing that VMA can trigger a WARN when recovering from a failed<br /> page table move due to a page table allocation error.<br /> <br /> The code ends up doing the right thing (recurse, avoiding moving actual<br /> page tables), but triggering that WARN is unpleasant:<br /> <br /> WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_normal_pmd mm/mremap.c:357 [inline]<br /> WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_pgt_entry mm/mremap.c:595 [inline]<br /> WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_page_tables+0x3832/0x44a0 mm/mremap.c:852<br /> Modules linked in:<br /> CPU: 2 UID: 0 PID: 6133 Comm: syz.0.19 Not tainted 6.17.0-rc1-syzkaller-00004-g53e760d89498 #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:move_normal_pmd mm/mremap.c:357 [inline]<br /> RIP: 0010:move_pgt_entry mm/mremap.c:595 [inline]<br /> RIP: 0010:move_page_tables+0x3832/0x44a0 mm/mremap.c:852<br /> Code: ...<br /> RSP: 0018:ffffc900037a76d8 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: 0000000032930007 RCX: ffffffff820c6645<br /> RDX: ffff88802e56a440 RSI: ffffffff820c7201 RDI: 0000000000000007<br /> RBP: ffff888037728fc0 R08: 0000000000000007 R09: 0000000000000000<br /> R10: 0000000032930007 R11: 0000000000000000 R12: 0000000000000000<br /> R13: ffffc900037a79a8 R14: 0000000000000001 R15: dffffc0000000000<br /> FS: 000055556316a500(0000) GS:ffff8880d68bc000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000001b30863fff CR3: 0000000050171000 CR4: 0000000000352ef0<br /> Call Trace:<br /> <br /> copy_vma_and_data+0x468/0x790 mm/mremap.c:1215<br /> move_vma+0x548/0x1780 mm/mremap.c:1282<br /> mremap_to+0x1b7/0x450 mm/mremap.c:1406<br /> do_mremap+0xfad/0x1f80 mm/mremap.c:1921<br /> __do_sys_mremap+0x119/0x170 mm/mremap.c:1977<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f00d0b8ebe9<br /> Code: ...<br /> RSP: 002b:00007ffe5ea5ee98 EFLAGS: 00000246 ORIG_RAX: 0000000000000019<br /> RAX: ffffffffffffffda RBX: 00007f00d0db5fa0 RCX: 00007f00d0b8ebe9<br /> RDX: 0000000000400000 RSI: 0000000000c00000 RDI: 0000200000000000<br /> RBP: 00007ffe5ea5eef0 R08: 0000200000c00000 R09: 0000000000000000<br /> R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000002<br /> R13: 00007f00d0db5fa0 R14: 00007f00d0db5fa0 R15: 0000000000000005<br /> <br /> <br /> The underlying issue is that we recurse during the original page table<br /> move, but not during the recovery move.<br /> <br /> Fix it by checking for both VMAs and performing the check before the<br /> pmd_none() sanity check.<br /> <br /> Add a new helper where we perform+document that check for the PMD and PUD<br /> level.<br /> <br /> Thanks to Harry for bisecting.