CVE-2026-31592

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SEV: Protect *all* of sev_mem_enc_register_region() with kvm-&gt;lock<br /> <br /> Take and hold kvm-&gt;lock for before checking sev_guest() in<br /> sev_mem_enc_register_region(), as sev_guest() isn&amp;#39;t stable unless kvm-&gt;lock<br /> is held (or KVM can guarantee KVM_SEV_INIT{2} has completed and can&amp;#39;t<br /> rollack state). If KVM_SEV_INIT{2} fails, KVM can end up trying to add to<br /> a not-yet-initialized sev-&gt;regions_list, e.g. triggering a #GP<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 110 UID: 0 PID: 72717 Comm: syz.15.11462 Tainted: G U W O 6.16.0-smp-DEV #1 NONE<br /> Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE<br /> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024<br /> RIP: 0010:sev_mem_enc_register_region+0x3f0/0x4f0 ../include/linux/list.h:83<br /> Code: 80 3c 04 00 74 08 4c 89 ff e8 f1 c7 a2 00 49 39 ed 0f 84 c6 00<br /> RSP: 0018:ffff88838647fbb8 EFLAGS: 00010256<br /> RAX: dffffc0000000000 RBX: 1ffff92015cf1e0b RCX: dffffc0000000000<br /> RDX: 0000000000000000 RSI: 0000000000001000 RDI: ffff888367870000<br /> RBP: ffffc900ae78f050 R08: ffffea000d9e0007 R09: 1ffffd4001b3c000<br /> R10: dffffc0000000000 R11: fffff94001b3c001 R12: 0000000000000000<br /> R13: ffff8982ab0bde00 R14: ffffc900ae78f058 R15: 0000000000000000<br /> FS: 00007f34e9dc66c0(0000) GS:ffff89ee64d33000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fe180adef98 CR3: 000000047210e000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> kvm_arch_vm_ioctl+0xa72/0x1240 ../arch/x86/kvm/x86.c:7371<br /> kvm_vm_ioctl+0x649/0x990 ../virt/kvm/kvm_main.c:5363<br /> __se_sys_ioctl+0x101/0x170 ../fs/ioctl.c:51<br /> do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x6f/0x1f0 ../arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f34e9f7e9a9<br /> Code: 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f34e9dc6038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007f34ea1a6080 RCX: 00007f34e9f7e9a9<br /> RDX: 0000200000000280 RSI: 000000008010aebb RDI: 0000000000000007<br /> RBP: 00007f34ea000d69 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 00007f34ea1a6080 R15: 00007ffce77197a8<br /> <br /> <br /> with a syzlang reproducer that looks like:<br /> <br /> syz_kvm_add_vcpu$x86(0x0, &amp;(0x7f0000000040)={0x0, &amp;(0x7f0000000180)=ANY=[], 0x70}) (async)<br /> syz_kvm_add_vcpu$x86(0x0, &amp;(0x7f0000000080)={0x0, &amp;(0x7f0000000180)=ANY=[@ANYBLOB="..."], 0x4f}) (async)<br /> r0 = openat$kvm(0xffffffffffffff9c, &amp;(0x7f0000000200), 0x0, 0x0)<br /> r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0)<br /> r2 = openat$kvm(0xffffffffffffff9c, &amp;(0x7f0000000240), 0x0, 0x0)<br /> r3 = ioctl$KVM_CREATE_VM(r2, 0xae01, 0x0)<br /> ioctl$KVM_SET_CLOCK(r3, 0xc008aeba, &amp;(0x7f0000000040)={0x1, 0x8, 0x0, 0x5625e9b0}) (async)<br /> ioctl$KVM_SET_PIT2(r3, 0x8010aebb, &amp;(0x7f0000000280)={[...], 0x5}) (async)<br /> ioctl$KVM_SET_PIT2(r1, 0x4070aea0, 0x0) (async)<br /> r4 = ioctl$KVM_CREATE_VM(0xffffffffffffffff, 0xae01, 0x0)<br /> openat$kvm(0xffffffffffffff9c, 0x0, 0x0, 0x0) (async)<br /> ioctl$KVM_SET_USER_MEMORY_REGION(r4, 0x4020ae46, &amp;(0x7f0000000400)={0x0, 0x0, 0x0, 0x2000, &amp;(0x7f0000001000/0x2000)=nil}) (async)<br /> r5 = ioctl$KVM_CREATE_VCPU(r4, 0xae41, 0x2)<br /> close(r0) (async)<br /> openat$kvm(0xffffffffffffff9c, &amp;(0x7f0000000000), 0x8000, 0x0) (async)<br /> ioctl$KVM_SET_GUEST_DEBUG(r5, 0x4048ae9b, &amp;(0x7f0000000300)={0x4376ea830d46549b, 0x0, [0x46, 0x0, 0x0, 0x0, 0x0, 0x1000]}) (async)<br /> ioctl$KVM_RUN(r5, 0xae80, 0x0)<br /> <br /> Opportunistically use guard() to avoid having to define a new error label<br /> and goto usage.