CVE-2025-39775
Gravedad:
Pendiente de análisis
Tipo:
No Disponible / Otro tipo
Fecha de publicación:
11/09/2025
Última modificación:
15/09/2025
Descripción
*** Pendiente de traducción *** 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()&#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.



