CVE-2025-40274

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: guest_memfd: Remove bindings on memslot deletion when gmem is dying<br /> <br /> When unbinding a memslot from a guest_memfd instance, remove the bindings<br /> even if the guest_memfd file is dying, i.e. even if its file refcount has<br /> gone to zero. If the memslot is freed before the file is fully released,<br /> nullifying the memslot side of the binding in kvm_gmem_release() will<br /> write to freed memory, as detected by syzbot+KASAN:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in kvm_gmem_release+0x176/0x440 virt/kvm/guest_memfd.c:353<br /> Write of size 8 at addr ffff88807befa508 by task syz.0.17/6022<br /> <br /> CPU: 0 UID: 0 PID: 6022 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xca/0x240 mm/kasan/report.c:482<br /> kasan_report+0x118/0x150 mm/kasan/report.c:595<br /> kvm_gmem_release+0x176/0x440 virt/kvm/guest_memfd.c:353<br /> __fput+0x44c/0xa70 fs/file_table.c:468<br /> task_work_run+0x1d4/0x260 kernel/task_work.c:227<br /> resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]<br /> exit_to_user_mode_loop+0xe9/0x130 kernel/entry/common.c:43<br /> exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]<br /> syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]<br /> syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]<br /> do_syscall_64+0x2bd/0xfa0 arch/x86/entry/syscall_64.c:100<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fbeeff8efc9<br /> <br /> <br /> Allocated by task 6023:<br /> kasan_save_stack mm/kasan/common.c:56 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:77<br /> poison_kmalloc_redzone mm/kasan/common.c:397 [inline]<br /> __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:414<br /> kasan_kmalloc include/linux/kasan.h:262 [inline]<br /> __kmalloc_cache_noprof+0x3e2/0x700 mm/slub.c:5758<br /> kmalloc_noprof include/linux/slab.h:957 [inline]<br /> kzalloc_noprof include/linux/slab.h:1094 [inline]<br /> kvm_set_memory_region+0x747/0xb90 virt/kvm/kvm_main.c:2104<br /> kvm_vm_ioctl_set_memory_region+0x6f/0xd0 virt/kvm/kvm_main.c:2154<br /> kvm_vm_ioctl+0x957/0xc60 virt/kvm/kvm_main.c:5201<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 6023:<br /> kasan_save_stack mm/kasan/common.c:56 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:77<br /> kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584<br /> poison_slab_object mm/kasan/common.c:252 [inline]<br /> __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:284<br /> kasan_slab_free include/linux/kasan.h:234 [inline]<br /> slab_free_hook mm/slub.c:2533 [inline]<br /> slab_free mm/slub.c:6622 [inline]<br /> kfree+0x19a/0x6d0 mm/slub.c:6829<br /> kvm_set_memory_region+0x9c4/0xb90 virt/kvm/kvm_main.c:2130<br /> kvm_vm_ioctl_set_memory_region+0x6f/0xd0 virt/kvm/kvm_main.c:2154<br /> kvm_vm_ioctl+0x957/0xc60 virt/kvm/kvm_main.c:5201<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Deliberately don&amp;#39;t acquire filemap invalid lock when the file is dying as<br /> the lifecycle of f_mapping is outside the purview of KVM. Dereferencing<br /> the mapping is *probably* fine, but there&amp;#39;s no need to invalidate anything<br /> as memslot deletion is responsible for zapping SPTEs, and the only code<br /> that can access the dying file is kvm_gmem_release(), whose core code is<br /> mutual<br /> ---truncated---