generated 2026-10-19 05:02 UTC
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching QEMU.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: fix NULL dereference of dlc->session in RFCOMM_CONNINFO
The RFCOMM_CONNINFO getsockopt handler accepts a socket that is not
connected as long as deferred setup is enabled:
if (sk->skstate != BTCONNECTED &&
!rfcommpi(sk)->dlc->defersetup) {
err = -ENOTCONN;
break;
}
l2capsk = rfcommpi(sk)->dlc->session->sock->sk;
dlc->defersetup is set in rfcommsockinit() when rfcommconnect_ind()
creates a child socket for an incoming connection on a listening socket
that has BTDEFERSETUP enabled. It is never cleared afterwards. The
session, however, can go away underneath it.
rfcommrecvdisc() forces the dlc state before tearing it down:
d->state = BT_CLOSED;
__rfcommdlcclose(d, err);
The RFCOMMDEFERSETUP early return in __rfcommdlcclose() only covers
BTCONNECT, BTCONFIG, BTOPEN and BTCONNECT2, so with the state
already BT_CLOSED that switch does not match and the function falls
through to rfcommdlcunlink(), which sets d->session = NULL, while
d->defer_setup stays 1.
A getsockopt(SOLRFCOMM, RFCOMMCONNINFO) on the accepted socket after
that point therefore skips the -ENOTCONN path -- sk->sk_state is
BTCLOSED, but dlc->defersetup is still set -- and dereferences the
NULL session. No race is needed: once the DISC has been processed, the
dereference is unconditional.
Reproduced on a KASAN kernel under QEMU with a BR/EDR peer emulated over
/dev/vhci: the peer brings up an ACL link, opens L2CAP on the RFCOMM
PSM, starts a session and sends SABM for a channel bound with
BTDEFERSETUP, and sends DISC for that dlci after the socket has been
accepted. getsockopt(SOLRFCOMM, RFCOMMCONNINFO) on the accepted
socket then hits:
Oops: general protection fault, probably for non-canonical address
0xdffffc0000000002: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 1 UID: 0 PID: 150 Comm: init Tainted: G B 7.3.0-rc3-g5dd1818b15d9
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:rfcommsockgetsockopt+0x529/0x780
Call Trace:
<TASK>
dosockgetsockopt+0x3ad/0x7d0
__sys_getsockopt+0x10e/0x1b0
__x64sysgetsockopt+0xc2/0x160
dosyscall64+0xda/0x4b0
entrySYSCALL64afterhwframe+0x77/0x7f
</TASK>
0x10 is the offset of sock in struct rfcomm_session;
rfcommsockgetsockoptold() is inlined into rfcommsock_getsockopt().
Commit 43a556b2fd43 ("Bluetooth: RFCOMM: take rfcomm_mutex for the
deferred setup accept") fixed the same "a remote DISC clears the session
while deferred setup is still flagged" problem in rfcommdlcaccept();
this is the remaining instance of it, in the getsockopt path.
Deferred setup only leaves a socket usable here once it has reached
BT_CONNECT2, so restrict the exception to that state and check that a
session is actually present before following it.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching QEMU.
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: fix NULL pointer dereference on fence allocation failure
virtiogpufence_alloc() can fail due to memory pressure and return NULL,
but its caller like virtiogpuinit_submit() never checks it. Later,
virtiogpuinit_submit() passes the NULL fence to
virtiogpufenceeventcreate(), which unconditionally dereferences it.
Found when fuzzing the virtio driver with Syzkaller:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]
CPU: 1 UID: 0 PID: 9991 Comm: syz.0.121 Not tainted 7.2.0 #4 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
RIP: 0010:virtiogpufenceeventcreate drivers/gpu/drm/virtio/virtgpu_submit.c:295 [inline]
RIP: 0010:virtiogpuinitsubmit drivers/gpu/drm/virtio/virtgpusubmit.c:398 [inline]
RIP: 0010:virtiogpuexecbufferioctl+0xc78/0x1aa0 drivers/gpu/drm/virtio/virtgpusubmit.c:505
Code: 85 ed 0f 85 21 09 00 00 e8 05 5a c9 fb 48 8b 44 24 10 48 8d b8 90 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 9a 0d 00 00 48 8b 44 24 10 4c 89 b0 90 00 00 00
RSP: 0018:ffffc900039dfad0 EFLAGS: 00010216
RAX: dffffc0000000000 RBX: ffffc900039dfdd8 RCX: ffffffff85f6fd3d
RDX: 0000000000000012 RSI: ffffffff85f6fd4b RDI: 0000000000000090
RBP: 0000000000000000 R0virtiogpuvirglprocesscmd: ctrl 0x102, error 0x1203
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880132c4000
R13: 0000000000000000 R14: ffff888073b6c700 R15: 000000000000003b
FS: 00007fab480b96c0(0000) GS:ffff8880eb6e9000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007effbf5e55a8 CR3: 0000000048d19000 CR4: 0000000000350ef0
Call Trace:
<TASK>
drmioctlkernel+0x1f4/0x3e0 drivers/gpu/drm/drm_ioctl.c:817
drmioctl+0x5f4/0xc70 drivers/gpu/drm/drmioctl.c:914
vfs_ioctl fs/ioctl.c:51 [inline]
__dosysioctl fs/ioctl.c:597 [inline]
__sesysioctl fs/ioctl.c:583 [inline]
__x64sysioctl+0x18e/0x210 fs/ioctl.c:583
dosyscallx64 arch/x86/entry/syscall_64.c:63 [inline]
dosyscall64+0x116/0x800 arch/x86/entry/syscall_64.c:94
entrySYSCALL64afterhwframe+0x77/0x7f
RIP: 0033:0x7fab471a82bd
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fab480b9018 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007fab47435fa0 RCX: 00007fab471a82bd
RDX: 00002000000000c0 RSI: 00000000c0406442 RDI: 0000000000000003
RBP: 00007fab480b9080 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
R13: 00007fab47436038 R14: 00007fab47435fa0 R15: 00007ffe85ab0740
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:virtiogpufenceeventcreate drivers/gpu/drm/virtio/virtgpu_submit.c:295 [inline]
RIP: 0010:virtiogpuinitsubmit drivers/gpu/drm/virtio/virtgpusubmit.c:398 [inline]
RIP: 0010:virtiogpuexecbufferioctl+0xc78/0x1aa0 drivers/gpu/drm/virtio/virtgpusubmit.c:505
Code: 85 ed 0f 85 21 09 00 00 e8 05 5a c9 fb 48 8b 44 24 10 48 8d b8 90 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 9a 0d 00 00 48 8b 44 24 10 4c 89 b0 90 00 00 00
RSP: 0018:ffffc900039dfad0 EFLAGS: 00010216
RAX: dffffc0000000000 RBX: ffffc900039dfdd8 RCX: ffffffff85f6fd3d
RDX: 0000000000000012 RSI: ffffffff85f6fd4b RDI: 0000000000000090
RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880132c4000
R13: 0000000000000000 R14: ffff888073b6c700 R15: 000000000000003b
FS: 00007fab480b96c0(0000) GS:ffff888098ae9000(0000) knlGS:00000000
---truncated---
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching QEMU.
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: don't bump pin count on failed re-pin in nouveaubopin_locked()
nouveaubopin_locked() checks whether an already pinned BO is in a
memory domain compatible with a new pin request. When the domains are
incompatible, it sets -EBUSY but still calls ttmbopin() before
returning.
Callers treat a failed nouveaubopin() as not having acquired a new pin,
so the extra pin count is never decreased by a matching unpin.
This triggers the warning in ttmborelease():
WARNONONCE(bo->pin_count);
Found when fuzzing the nouveau driver with a modified Syzkaller:
WARNING: drivers/gpu/drm/ttm/ttmbo.c:256 at ttmborelease+0x827/0x9e0 drivers/gpu/drm/ttm/ttmbo.c:256, CPU#1: syz.3.24/2212
Modules linked in:
CPU: 1 UID: 0 PID: 2212 Comm: syz.3.24 Not tainted 7.2.0 #24 PREEMPT(lazy)
nouveau 0000:01:00.0: gsp:msg fn:103 len:0x40/0x20 res:0x19 resp:0x19
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:ttmborelease+0x827/0x9e0 drivers/gpu/drm/ttm/ttm_bo.c:256
Code: 02 00 0f 85 51 01 00 00 48 8b 7b 08 e8 d2 20 01 00 e9 80 fd ff ff e8 d8 15 c0 fe 90 0f 0b 90 e9 e1 f8 ff ff e8 ca 15 c0 fe 90 <0f> 0b 90 e9 a4 f8 ff ff e8 bc 15 c0 fe be 03 00 00 00 4c 89 e7 e8
msg: 00000000: 05 00 d0 c1 04 00 f0 f1 01 30 00 00 2d 90 00 00 .........0..-...
RSP: 0018:ffffc9000f5cf710 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff888018e5d2a8 RCX: ffffffff82bb1b36
RDX: ffff888017b68000 RSI: 0000000000000004 RDI: ffff888018e5d2a8
msg: 00000010: 19 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
RBP: ffff88801261c720 R08: 0000000000000001 R09: ffffed10031cba55
R10: ffff888018e5d2ab R11: 00000000000000f3 R12: ffff888018e5d290
R13: ffff888018e5d2d4 R14: ffff88801b219c18 R15: dffffc0000000000
FS: 0000000000000000(0000) GS:ffff8880e0f6f000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b31223ffc CR3: 0000000028e00005 CR4: 0000000000770ef0
PKRU: 80000000
Call Trace:
<TASK>
kref_put include/linux/kref.h:65 [inline]
ttmboput drivers/gpu/drm/ttm/ttm_bo.c:325 [inline]
ttmbofini+0x55/0x80 drivers/gpu/drm/ttm/ttm_bo.c:330
nouveaugemobjectdel+0xb2/0x1b0 drivers/gpu/drm/nouveau/nouveaugem.c:90
drmgemobjectfree+0x5f/0x90 drivers/gpu/drm/drmgem.c:1165
kref_put include/linux/kref.h:65 [inline]
__drmgemobjectput include/drm/drmgem.h:562 [inline]
drmgemobjectput include/drm/drmgem.h:575 [inline]
nouveauabi16chanfini.constprop.0+0x44f/0x5a0 drivers/gpu/drm/nouveau/nouveauabi16.c:195
nouveau 0000:01:00.0: syz.2.23[2209]: Unknown handle 0x00000000
nouveauabi16fini+0x1d0/0x340 drivers/gpu/drm/nouveau/nouveau_abi16.c:225
nouveaudrmpostclose+0x18b/0x3e0 drivers/gpu/drm/nouveau/nouveau_drm.c:1284
nouveau 0000:01:00.0: syz.2.23[2209]: validate_init
drmfilefree.part.0+0x6d6/0xb60 drivers/gpu/drm/drm_file.c:267
drmfilefree drivers/gpu/drm/drm_file.c:237 [inline]
drmclosehelper.isra.0+0x11a/0x160 drivers/gpu/drm/drm_file.c:290
drmrelease+0x1ab/0x330 drivers/gpu/drm/drmfile.c:438
__fput+0x39c/0xa60 fs/file_table.c:512
nouveau 0000:01:00.0: syz.2.23[2209]: validate: -2
taskworkrun+0x15a/0x230 kernel/task_work.c:233
exittaskwork include/linux/task_work.h:40 [inline]
do_exit+0x82b/0x25a0 kernel/exit.c:1009
dogroupexit+0xc2/0x280 kernel/exit.c:1152
get_signal+0x1d6e/0x1f30 kernel/signal.c:3046
archdosignalorrestart+0x7d/0x6e0 arch/x86/kernel/signal.c:337
__exittousermodeloop kernel/entry/common.c:66 [inline]
exittousermodeloop+0xdf/0x440 kernel/entry/common.c:101
__exittousermodeprepare include/linux/irq-entry-common.h:207 [inline]
syscallexittousermode_prepare include/linux/irq-entry-common.h:230 [inline]
syscallexittousermode include/linux/entry-common.h:318 [inline]
dosyscall64+0x4f8/0x690 arch/x86/entry/syscall_64.c:100
entrySYSCALL64afterhwframe+0x77/0x7f
RI
---truncated---
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching QEMU.
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: fix double-free in nvifvmmdtor
On failure, nouveaucliinit() calls nouveauclifini() to tear
the client down. Then, nouveaudrmopen() also enters into its
cleanup path and calls nouveauclifini() AGAIN. nouveauclifini()
calls nouveauvmmfini():
void
nouveauvmmfini(struct nouveau_vmm *vmm)
{
nouveausvmmfini(&vmm->svmm);
nvifvmmdtor(&vmm->vmm);
vmm->cli = NULL;
}
Inside nvifvmmdtor(), vmm->page is freed unconditionally:
void
nvifvmmdtor(struct nvif_vmm *vmm)
{
kfree(vmm->page);
nvifobjectdtor(&vmm->object);
}
vmm->page is never cleared after being freed, so the second call of
nvifvmmdtor() will cause a double-free.
Found by fuzzing the nouveau driver with a modified Syzkaller:
BUG: KASAN: double-free in nvifvmmdtor+0x31/0x50 drivers/gpu/drm/nouveau/nvif/vmm.c:194
Free of addr ffff888010fcdc30 by task syz.0.173/2567
CPU: 1 UID: 0 PID: 2567 Comm: syz.0.173 Not tainted 7.2.0 #24 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<TASK>
__dumpstack lib/dumpstack.c:94 [inline]
dumpstacklvl+0x95/0xe0 lib/dump_stack.c:120
printaddressdescription mm/kasan/report.c:378 [inline]
print_report+0xcb/0x5a0 mm/kasan/report.c:482
kasanreportinvalid_free+0xaa/0xd0 mm/kasan/report.c:557
checkslaballocation+0xe4/0x110 mm/kasan/common.c:235
kasanslabpre_free include/linux/kasan.h:199 [inline]
slabfreehook mm/slub.c:2622 [inline]
slab_free mm/slub.c:6377 [inline]
kfree+0x192/0x590 mm/slub.c:6692
nvifvmmdtor+0x31/0x50 drivers/gpu/drm/nouveau/nvif/vmm.c:194
nouveauvmmfini+0x16/0x50 drivers/gpu/drm/nouveau/nouveau_vmm.c:127
nouveauclifini+0x10e/0x210 drivers/gpu/drm/nouveau/nouveau_drm.c:225
nouveaudrmopen+0x24e/0x740 drivers/gpu/drm/nouveau/nouveau_drm.c:1255
drmfilealloc+0x5f2/0xad0 drivers/gpu/drm/drm_file.c:176
drmopenhelper+0x1d7/0x4a0 drivers/gpu/drm/drm_file.c:335
drmopen+0x190/0x3d0 drivers/gpu/drm/drmfile.c:388
drmstubopen+0x1f2/0x460 drivers/gpu/drm/drm_drv.c:1211
chrdevopen+0x21c/0x660 fs/chardev.c:411
dodentryopen+0x59d/0x12b0 fs/open.c:947
vfs_open+0x82/0x390 fs/open.c:1052
do_open fs/namei.c:4700 [inline]
path_openat+0x2345/0x3420 fs/namei.c:4863
dofileopen+0x207/0x460 fs/namei.c:4892
dosysopenat2+0xd1/0x1d0 fs/open.c:1368
dosysopen fs/open.c:1374 [inline]
__dosysopenat fs/open.c:1390 [inline]
__sesysopenat fs/open.c:1385 [inline]
__x64sysopenat+0x144/0x200 fs/open.c:1385
dosyscallx64 arch/x86/entry/syscall_64.c:63 [inline]
dosyscall64+0x115/0x690 arch/x86/entry/syscall_64.c:94
entrySYSCALL64afterhwframe+0x77/0x7f
RIP: 0033:0x7fc6d687594d
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fc6d5295008 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 00007fc6d6b06180 RCX: 00007fc6d687594d
RDX: 0000000000022501 RSI: 0000200000000000 RDI: ffffffffffffff9c
RBP: 00007fc6d691c303 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fc6d6b06218 R14: 00007fc6d6b06180 R15: 00007ffd9451d760
</TASK>
Allocated by task 2567 on cpu 1 at 163.593900s:
kasansavestack+0x24/0x50 mm/kasan/common.c:57
kasansavetrack+0x17/0x60 mm/kasan/common.c:78
poisonkmallocredzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:263 [inline]
__dokmallocnode mm/slub.c:5334 [inline]
__kmalloc_noprof+0x304/0x7c0 mm/slub.c:5359
kmallocnoprof include/linux/slab.h:992 [inline]
nvifvmmctor+0x3c0/0x7e0 drivers/gpu/drm/nouveau/nvif/vmm.c:237
nouveauvmminit+0x40/0x90 drivers/gpu/drm/nouveau/nouveau_vmm.c:134
nouveaucliinit+0x7b9/0
---truncated---
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching QEMU.
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/uvmm: fix UAF in nouveauuvmmsm when BO is in TTMPLSYSTEM
nouveauuvmmsm() calls op_map(), which passes bo->resource through
nouveaumem() to nouveauuvmamap(). nouveauuvmmvmmmap() then reads
mem->mem.type.
But this is only valid when bo->resource is backed by struct nouveau_mem,
as is the case for VRAM and TT resources. If the BO is left in
TTMPLSYSTEM, bo->resource is only a struct ttm_resource. Treating it
as struct nouveau_mem makes the mem->mem.type read past the end of the
resource, causing a KASAN: slab-use-after-free Read in nouveauuvmmsm
report:
BUG: KASAN: slab-use-after-free in nouveauuvmmvmmmap drivers/gpu/drm/nouveau/nouveauuvmm.c:152 [inline]
BUG: KASAN: slab-use-after-free in nouveauuvmamap drivers/gpu/drm/nouveau/nouveau_uvmm.c:199 [inline]
BUG: KASAN: slab-use-after-free in opmap drivers/gpu/drm/nouveau/nouveauuvmm.c:849 [inline]
BUG: KASAN: slab-use-after-free in nouveauuvmmsm.constprop.0+0x6ab/0x900 drivers/gpu/drm/nouveau/nouveau_uvmm.c:903
Read of size 1 at addr ffff888127d3e3a0 by task kworker/0:1/11
CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 7.2.0 #5 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: nouveauschedwq2224 drmschedrunjob_work
Call Trace:
<TASK>
__dumpstack lib/dumpstack.c:94 [inline]
dumpstacklvl+0x95/0xe0 lib/dump_stack.c:120
printaddressdescription mm/kasan/report.c:378 [inline]
print_report+0xcb/0x5a0 mm/kasan/report.c:482
kasan_report+0xca/0x100 mm/kasan/report.c:595
nouveauuvmmvmmmap drivers/gpu/drm/nouveau/nouveauuvmm.c:152 [inline]
nouveauuvmamap drivers/gpu/drm/nouveau/nouveau_uvmm.c:199 [inline]
opmap drivers/gpu/drm/nouveau/nouveauuvmm.c:849 [inline]
nouveauuvmmsm.constprop.0+0x6ab/0x900 drivers/gpu/drm/nouveau/nouveau_uvmm.c:903
nouveauuvmmsmunmap drivers/gpu/drm/nouveau/nouveauuvmm.c:932 [inline]
nouveauuvmmbindjobrun+0xd6/0x250 drivers/gpu/drm/nouveau/nouveau_uvmm.c:1532
nouveaujobrun drivers/gpu/drm/nouveau/nouveau_sched.c:350 [inline]
nouveauschedrunjob+0x62/0xd0 drivers/gpu/drm/nouveau/nouveausched.c:364
drmschedrunjobwork+0x356/0xa10 drivers/gpu/drm/scheduler/sched_main.c:1061
processonework+0x8a5/0x1900 kernel/workqueue.c:3322
processscheduledworks kernel/workqueue.c:3405 [inline]
worker_thread+0x5dd/0xd80 kernel/workqueue.c:3486
kthread+0x31d/0x420 kernel/kthread.c:436
retfromfork+0x662/0x940 arch/x86/kernel/process.c:158
retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245
</TASK>
Allocated by task 2224 on cpu 0 at 66.550027s:
kasansavestack+0x24/0x50 mm/kasan/common.c:57
kasansavetrack+0x17/0x60 mm/kasan/common.c:78
poisonkmallocredzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:263 [inline]
__dokmallocnode mm/slub.c:5334 [inline]
__kmalloc_noprof+0x304/0x7c0 mm/slub.c:5359
kmallocnoprof include/linux/slab.h:992 [inline]
dmaresvlist_alloc+0x27/0x90 drivers/dma-buf/dma-resv.c:106
dmaresvreserve_fences+0x60e/0xa30 drivers/dma-buf/dma-resv.c:205
ttmboallocresource+0x12c/0xbd0 drivers/gpu/drm/ttm/ttmbo.c:721
ttmbovalidate+0x1bc/0x4a0 drivers/gpu/drm/ttm/ttm_bo.c:856
ttmboinitreserved+0x2c3/0x570 drivers/gpu/drm/ttm/ttmbo.c:970
nouveauboinit+0x159/0x2c0 drivers/gpu/drm/nouveau/nouveau_bo.c:359
nouveaugemnew+0x234/0x5f0 drivers/gpu/drm/nouveau/nouveau_gem.c:272
nouveaugemioctlnew+0x1eb/0x420 drivers/gpu/drm/nouveau/nouveaugem.c:352
drmioctlkernel+0x192/0x350 drivers/gpu/drm/drm_ioctl.c:817
drmioctl+0x4f8/0xb40 drivers/gpu/drm/drmioctl.c:914
nouveaudrmioctl+0xea/0x2c0 drivers/gpu/drm/nouveau/nouveau_drm.c:1338
vfs_ioctl fs/ioctl.c:51 [inline]
__dosysioctl fs/ioctl.c:597 [inline]
__sesysioctl fs/ioctl.c:583 [inline]
__x64sysioctl+0x180/0x1d0 fs/ioctl.c:583
dosyscallx64 ar
---truncated---
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching QEMU.
In the Linux kernel, the following vulnerability has been resolved:
mctp: route: iterate socket tag list in mctplookupprealloc_tag()
When a socket transmits a packet with MCTPTAGPREALLOC set,
mctplookupprealloc_tag() iterates over the per-netns &mns->keys list
and matches netid, reqtag, peeraddr, and manual_alloc, without
checking whether tmp->sk == &msk->sk. This allows any MCTP socket in the
same network namespace to use and consume another socket's preallocated
tag.
Iterate the socket's own tag list (&msk->keys via sklist) instead of the
namespace-wide &mns->keys list in mctplookupprealloc_tag(), ensuring
that only tags allocated by msk are matched.
Tested in QEMU against Linux 7.3.0-rc3 by allocating a manual tag
(0x18) on socket A via SIOCMCTPALLOCTAG for peer EID 9 and sending a
4-byte message with MCTPTAGPREALLOC from socket B in the same network
namespace. On the unfixed kernel, sendto(sock_b) using socket A's
preallocated tag succeeds (ret = 4); with this patch applied,
sendto(sockb) fails with -ENOENT (errno = 2) while sendto(socka)
succeeds (ret = 4).
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching QEMU.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: enforce exact attribute length for SEG6ATTRDST
In seg6genlpolicy, SEG6ATTRDST is defined with .type = NLA_BINARY and
.len = sizeof(struct in6addr). For NLABINARY, .len only enforces the
maximum payload length and permits shorter payloads (e.g., 0 bytes).
When seg6genlsettunsrc() copies sizeof(struct in6addr) bytes via
kmemdup(val, sizeof(*val), GFPKERNEL), a short SEG6ATTR_DST attribute
triggers a 16-byte out-of-bounds read past skb->tail into uninitialized
skb->head memory, which is stored in sdata->tun_src and leaked back to
userspace via SEG6CMDGET_TUNSRC.
Switch SEG6ATTRDST in seg6genlpolicy to
NLAPOLICYEXACTLEN(sizeof(struct in6addr)) so that generic netlink
validation rejects any attribute whose length is not exactly
sizeof(struct in6_addr) with -ERANGE.
Tested in QEMU against Linux 7.3.0-rc3 by sending a SEG6CMDSET_TUNSRC
Generic Netlink message with a 0-byte SEG6ATTRDST attribute followed
by SEG6CMDGETTUNSRC. On the unfixed kernel, SEG6CMDSETTUNSRC
succeeds (err = 0) and SEG6CMDGET_TUNSRC leaks 16 bytes of
uninitialized kernel heap memory (tun_src =
836a61ecc4d25a1042a8d60411cfb378); with this patch applied,
SEG6CMDSET_TUNSRC is rejected by netlink policy validation with
-ERANGE (-34) and tun_src remains zeroed.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching QEMU.
In the Linux kernel, the following vulnerability has been resolved:
fou: reject omitted FOUATTRIPPROTO on FOUENCAPDIRECT
Commit 7a9bc9e3f423 ("fou: Don't allow 0 for FOUATTRIPPROTO.") added
NLAPOLICYMIN(NLAU8, 1) to founlpolicy[FOUATTR_IPPROTO], which
rejects an explicitly supplied FOUATTRIPPROTO == 0 attribute with
-ERANGE.
However, FOUATTRIPPROTO is an optional netlink attribute. When a user
sends FOUCMDADD with FOUATTRTYPE set to FOUENCAPDIRECT and omits
FOUATTRIPPROTO entirely, nla_policy validation succeeds and
parsenlconfig() leaves cfg->protocol as 0 (from memset(cfg, 0,
sizeof(*cfg))). foucreate() then creates a FOUENCAP_DIRECT socket with
fou->protocol == 0.
In fouudprecv(), returning -fou->protocol to udpqueuercvoneskb()
triggers IP protocol resubmission when fou->protocol > 0, whereas
returning 0 tells the UDP tunnel layer that the skb was consumed without
freeing it. When fou->protocol == 0, every packet received on the socket
returns 0 from fouudprecv() and leaks the sk_buff.
Reject FOUENCAPDIRECT when !cfg->protocol in fou_create() so that
creating a direct encapsulation port without FOUATTRIPPROTO fails with
-EINVAL while leaving FOUCMDDEL and FOUCMDGET (which share
parsenlconfig()) unaffected.
Tested in QEMU against Linux 7.3.0-rc3 by sending a FOUCMDADD Generic
Netlink request with FOUATTRPORT = 5555 and FOUATTRTYPE =
FOUENCAPDIRECT while omitting FOUATTRIPPROTO. On the unfixed kernel,
FOUCMDADD succeeds (err = 0), FOUCMDGET reports fou->type = 1 and
fou->protocol = 0, and sending 4000 UDP packets to 127.0.0.1:5555 leaks
all 4000 sk_buffs (SUnreclaim in /proc/meminfo grows from 41456 kB to
59008 kB, +17552 kB); with this patch applied, FOUCMDADD is rejected
with -EINVAL (-22).
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching QEMU.
In the Linux kernel, the following vulnerability has been resolved:
cgroup/cpuset: Return PERRNOCPUS in remotepartitionenable() on subpartitionscpus conflict
When a remote partition is created underneath an existing local partition
via a non-partition (PRSMEMBER) intermediate cgroup, updateprstate() sees
parent->partitionrootstate == PRS_MEMBER and calls
remotepartitionenable().
Commit 86888c7bd117 ("cgroup/cpuset: Add warnings to catch inconsistency
in exclusive CPUs") replaced the cpumaskintersects(tmp->newcpus,
subpartitionscpus) error check in remotepartition_enable() with
WARNONONCE(). As a result, remotepartitionenable() emits a warning
and proceeds to enable the remote partition on CPUs that are already
owned by the ancestor local partition in subpartitions_cpus.
This can be reproduced on Linux 7.3.0-rc3 with:
mkdir -p /tmp/cg1
mount -t cgroup2 none /tmp/cg1
echo "+cpuset" > /tmp/cg1/cgroup.subtree_control
mkdir /tmp/cg1/A
echo 1 > /tmp/cg1/A/cpuset.cpus
echo 1 > /tmp/cg1/A/cpuset.cpus.exclusive
echo root > /tmp/cg1/A/cpuset.cpus.partition
echo "+cpuset" > /tmp/cg1/A/cgroup.subtree_control
mkdir /tmp/cg1/A/B
echo 1 > /tmp/cg1/A/B/cpuset.cpus
echo 1 > /tmp/cg1/A/B/cpuset.cpus.exclusive
echo "+cpuset" > /tmp/cg1/A/B/cgroup.subtree_control
mkdir /tmp/cg1/A/B/D
echo 1 > /tmp/cg1/A/B/D/cpuset.cpus
echo 1 > /tmp/cg1/A/B/D/cpuset.cpus.exclusive
echo root > /tmp/cg1/A/B/D/cpuset.cpus.partition
which triggers:
WARNING: kernel/cgroup/cpuset.c:1594 at remotepartitionenable+0x1c1/0x300
and leaves both /tmp/cg1/A and /tmp/cg1/A/B/D as active root partitions
claiming exclusive CPU 1.
Fix this by returning PERRNOCPUS when tmp->newcpus intersects
subpartitionscpus in remotepartition_enable(), matching the error code
used by remotecpusupdate() for the same subpartitions_cpus conflict, and
add a regression test case to
tools/testing/selftests/cgroup/testcpusetprs.sh.
Tested in QEMU on Linux 7.3.0-rc3 using the reproducer above and
tools/testing/selftests/cgroup/testcpusetprs.sh.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching QEMU.
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-scsi: bound the ATA passthru sense descriptor writes
When an ATA PASS-THROUGH command to an ATAPI device fails, the sense
buffer holds the device's REQUEST SENSE reply, and
atascsisetpassthrusense_fields() trusts its additional length
byte, sb[7], when adding the ATA Status Return descriptor. A faulty
or malicious device can use that to make the kernel read and write
past the 96-byte buffer in three ways:
its clamp against sb[7] does nothing and the walk runs off the end.
so len 75..82 writes up to 8 bytes past the end.
Reproduced with KASAN under qemu, with the emulated ATAPI REQUEST SENSE
reply patched:
BUG: KASAN: slab-out-of-bounds in scsisensedesc_find+0x1a5/0x210
BUG: KASAN: slab-out-of-bounds in atascsiqc_complete+0x1a15/0x1a50
Both are gone with this patch, and a valid descriptor is still filled
in.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching QEMU.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix immediate JMP JEQ/JNE on MIPS32
An addu instruction was emitted instead of addiu, causing the immediate
value 1 to be interpreted as register $at. This made the comparison
result invalid when the immediate operand was negative. Note that $at
is mapped to BPFREGAX, which is used for constant blinding.
Fix the instruction to use the immediate form.
Found with test_bpf on MIPS32r1 emulated by QEMU.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching QEMU.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: actct: don't WARN on benign flowoffload_alloc() failure
flowoffloadalloc() returns NULL when the conntrack entry is dying
(e.g. raced with a conntrack flush) or when the GFP_ATOMIC allocation
fails; both are expected under load and neither is a kernel bug. This
path runs from softirq on every committed packet, so with
paniconwarn=1 an unprivileged user can panic the box just by racing
a conntrack flush against a tc ... action ct commit classifier.
Reproduced with a custom repro under QEMU: a small, fixed set of UDP
flows through tc filter ... action ct commit on lo, raced against
threads flooding bare ctnetlink CT_DELETE (flush) requests. Hits
WARNING: net/sched/actct.c:437 (tcfctflowtable_add(), inlined
into tcfctact() in this build) within ~15s on the unpatched kernel;
same setup is clean on the patched kernel. The fix itself is
behavior-preserving: both branches already did goto err_alloc
before and after, only the WARN is removed.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM, QEMU.
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/mmu: Bail from shadow walks if the root is invalid or a dummy
When walking shadow page tables, immediately terminate the walk if the root
is a "dummy" root, i.e. a root whose top-level page table is backed by the
zero page, but otherwise doesn't exist. If memslot creation races with a
stage-2 page fault (EPT violation or #NPF) from L2, then if the stars align,
KVM will attempt to walk shadow page tables using the zero page and hit a
NULL pointer deref.
BUG: kernel NULL pointer dereference, address: 0000000000000021
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP
CPU: 30 UID: 1000 PID: 941 Comm: qemu Not tainted 7.2.0-rc2-1b731e5ded48-next-vm #1741 PREEMPTLAZY
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:__kvmmmuinvalidate_addr+0xea/0x210 [kvm]
Call Trace:
<TASK>
kvmmmuinvalidate_addr+0x92/0xe0 [kvm]
__kvminjectemulatedpagefault+0x67/0x80 [kvm]
eptpagefault+0x160/0x850 [kvm]
kvmmmudopagefault+0x102/0x1f0 [kvm]
kvmmmupage_fault+0x8e/0x6b0 [kvm]
vmxhandleexit+0x163/0x640 [kvm_intel]
kvmarchvcpuioctlrun+0x960/0x2120 [kvm]
kvmvcpuioctl+0x2c7/0x970 [kvm]
__x64sysioctl+0x90/0xd0
dosyscall64+0x67/0x5f0
entrySYSCALL64afterhwframe+0x4b/0x53
RIP: 0033:0x7f606d0b53bb
Opportunistically harden the shadow walks against fully invalid roots, but
WARN, as all callers are expected/required to pre-check for a valid root.
Don't WARN in the dummy root case as the whole point of using a dummy root
is to provide a root that's valid enough to enter the guest, i.e. it should
Just Work for all flows except those that need to know about dummy roots.
Alternatively, KVM could allocate a dedicated page and associated shadow
page structure for the dummy root, which is very tempting as it such an
approach should be more resilient against unexpected behavior. But that
would be a much larger and thus riskier change than simply terminating
walks of dummy roots.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching QEMU.
In the Linux kernel, the following vulnerability has been resolved:
usb: core: clear both epin and epout for non-ep0 control endpoints
In usbenableendpoint(), non-zero control endpoints (where
usbendpointxfer_control(&ep->desc) is true) populate both
dev->epin[epnum] and dev->epout[epnum] with the same struct
usbhostendpoint pointer.
However, usbdisableendpoint() only clears either dev->ep_out[epnum] or
dev->ep_in[epnum] depending on the direction bit of epaddr when
reset_hardware is set, leaving the opposite direction's array slot
pointing to the disabled/freed endpoint.
Clear both dev->epout[epnum] and dev->epin[epnum] when disabling a
non-ep0 control endpoint with reset_hardware set, and update the
function kerneldoc accordingly.
Tested in QEMU against Linux 7.3.0-rc3 using dummy_hcd and raw-gadget to
enumerate a USB device with a non-zero control endpoint
(bEndpointAddress 0x01, bmAttributes USBENDPOINTXFER_CONTROL),
verifying that both dev->epin[1] and dev->epout[1] are cleared when
the interface is disabled.
References:
Operating Systems, Virtualization/Hypervisors, published 2026-10-18
Flagged for matching QEMU, Ubuntu.
In the Linux kernel, the following vulnerability has been resolved:
binderfs: fix UAF write in binderadddevice
binderfsbinderdevice_create() publishes the new dentry with
dmakepersistent() and then calls simpledonecreating(), which drops
the parent directory lock and the creator's dentry reference. It then
calls binderadddevice() to register the device in the global
binder_devices list.
After simpledonecreating() releases the parent directory lock, a
concurrent unlinkat() can remove the new device entry. Dropping the
creator's dentry reference can then trigger binderfsevictinode(),
freeing the device. binderadddevice() later accesses the freed
object, causing UAF write.
Found by a modified Syzkaller:
BUG: KASAN: slab-use-after-free in hlistaddhead include/linux/list.h:1073 [inline]
BUG: KASAN: slab-use-after-free in binderadddevice+0xa9/0xc0 drivers/android/binder.c:7068
Write of size 8 at addr ffff88805b340c00 by task syz.1.532/11389
CPU: 0 UID: 0 PID: 11389 Comm: syz.1.532 Not tainted 7.2.0 #4 PREEMPT(full)
Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<TASK>
__dumpstack lib/dumpstack.c:94 [inline]
dumpstacklvl+0x10e/0x1f0 lib/dump_stack.c:120
printaddressdescription mm/kasan/report.c:378 [inline]
print_report+0xf7/0x600 mm/kasan/report.c:482
kasan_report+0xe4/0x120 mm/kasan/report.c:595
hlistaddhead include/linux/list.h:1073 [inline]
binderadddevice+0xa9/0xc0 drivers/android/binder.c:7068
binderfsbinderdevice_create.isra.0+0x724/0x990 drivers/android/binderfs.c:196
binderctlioctl+0x186/0x1b0 drivers/android/binderfs.c:241
vfs_ioctl fs/ioctl.c:51 [inline]
__dosysioctl fs/ioctl.c:597 [inline]
__sesysioctl fs/ioctl.c:583 [inline]
__x64sysioctl+0x18e/0x210 fs/ioctl.c:583
dosyscallx64 arch/x86/entry/syscall_64.c:63 [inline]
dosyscall64+0x116/0x800 arch/x86/entry/syscall_64.c:94
entrySYSCALL64afterhwframe+0x77/0x7f
RIP: 0033:0x7ff9027a833d
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ff903674018 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007ff902a35fa0 RCX: 00007ff9027a833d
RDX: 0000200000000500 RSI: 00000000c1086201 RDI: 0000000000000004
RBP: 00007ff902850733 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ff902a36038 R14: 00007ff902a35fa0 R15: 00007ffd7166bfa0
</TASK>
Allocated by task 11389:
kasansavestack+0x33/0x60 mm/kasan/common.c:57
kasansavetrack+0x14/0x30 mm/kasan/common.c:78
poisonkmallocredzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:263 [inline]
__kmalloccachenoprof+0x2e4/0x6f0 mm/slub.c:5489
kmallocnoprof include/linux/slab.h:988 [inline]
kzallocnoprof include/linux/slab.h:1309 [inline]
binderfsbinderdevice_create.isra.0+0x17a/0x990 drivers/android/binderfs.c:148
binderctlioctl+0x186/0x1b0 drivers/android/binderfs.c:241
vfs_ioctl fs/ioctl.c:51 [inline]
__dosysioctl fs/ioctl.c:597 [inline]
__sesysioctl fs/ioctl.c:583 [inline]
__x64sysioctl+0x18e/0x210 fs/ioctl.c:583
dosyscallx64 arch/x86/entry/syscall_64.c:63 [inline]
dosyscall64+0x116/0x800 arch/x86/entry/syscall_64.c:94
entrySYSCALL64afterhwframe+0x77/0x7f
Freed by task 11389:
kasansavestack+0x33/0x60 mm/kasan/common.c:57
kasansavetrack+0x14/0x30 mm/kasan/common.c:78
kasansavefree_info+0x3b/0x60 mm/kasan/generic.c:584
poisonslabobject mm/kasan/common.c:253 [inline]
__kasanslabfree+0x5f/0x80 mm/kasan/common.c:285
kasanslabfree include/linux/kasan.h:235 [inline]
slabfreehook mm/slub.c:2677 [inline]
slab_free mm/slub.c:6377 [inline]
kfree+0x2fc/0x6e0 mm/slub.c:6692
binderf
---truncated---
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching QEMU.
In the Linux kernel, the following vulnerability has been resolved:
nvme: fix cdev lifetime
Sashiko bot reported a potential problem for the cdev lifetime in [0]
Currently the NS head .open and .release file_operations methods take and
put a reference to the nvmenshead to ensure that this structure does not
disappear while we open fds for that cdev.
In multipath mode, when we teardown the NS head, we call nvmecdevdel() ->
cdevdevicedel() -> cdevdel(). However after cdevdel() returns, cdevs
already open will remain and their fops will still be callable. As such,
we can still reference the cdev after the nvmenshead reference count
drops to 0 (and is freed).
This can be shown with an application which delays between opening the cdev
and issuing the ioctl while the NS head is being torn down:
[ 21.221718] nvme nvme1: Removing ctrl: NQN "nvme-test-target"
[ 21.274609] nvme nvme2: Removing ctrl: NQN "nvme-test-target"
[ 26.549285] ==================================================================
[ 26.550841] BUG: KASAN: slab-use-after-free in cdev_put.part.0+0x3d/0x40
[ 26.552352] Read of size 8 at addr ffff88811e7fa170 by task ioctl_file/237
[ 26.553805]
[ 26.554227] CPU: 3 UID: 0 PID: 237 Comm: ioctl_file Not tainted 7.2.0-rc1-00004-g6852a10e32d4 #921 PREEMPT(lazy)
[ 26.554236] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 26.554241] Call Trace:
[ 26.554245] <TASK>
[ 26.554248] dumpstacklvl+0x68/0xa0
[ 26.554266] print_report+0x10d/0x5d0
[ 26.554276] ? __virtaddrvalid+0x21d/0x3f0
[ 26.554287] ? cdev_put.part.0+0x3d/0x40
[ 26.554292] kasan_report+0x96/0xd0
[ 26.554300] ? cdev_put.part.0+0x3d/0x40
[ 26.554307] cdev_put.part.0+0x3d/0x40
[ 26.554313] __fput+0x7bc/0xa70
[ 26.554322] fputclosesync+0xd8/0x190
[ 26.554328] ? __pfxfputclose_sync+0x10/0x10
[ 26.554337] __x64sysclose+0x79/0xd0
[ 26.554344] dosyscall64+0x117/0x6b0
[ 26.554351] entrySYSCALL64afterhwframe+0x77/0x7f
[ 26.554358] RIP: 0033:0x7f938c067727
[ 26.554364] Code: 48 89 fa 4c 89 df e8 28 ad 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5bf
[ 26.554369] RSP: 002b:00007fff49f05980 EFLAGS: 00000202 ORIG_RAX: 0000000000000003
[ 26.554376] RAX: ffffffffffffffda RBX: 00007f938bfd7780 RCX: 00007f938c067727
[ 26.554380] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
[ 26.554383] RBP: 00007fff49f05a10 R08: 0000000000000000 R09: 0000000000000000
[ 26.554386] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
[ 26.554389] R13: 00007fff49f05b40 R14: 00007f938c207000 R15: 000055c148471d78
[ 26.554397] </TASK>
[ 26.554399]
[ 26.575612] Allocated by task 100:
[ 26.575871] kasansavestack+0x24/0x50
[ 26.576157] kasansavetrack+0x14/0x30
[ 26.576418] __kasan_kmalloc+0x7f/0x90
[ 26.576668] __kmalloc_noprof+0x281/0x6c0
[ 26.576938] nvmeallocns+0x7f7/0x3170
[ 26.577206] nvmescanns+0x508/0x880
[ 26.577449] asyncrunentry_fn+0x8c/0x350
[ 26.577723] processscheduledworks+0xb6f/0x1a00
[ 26.578034] worker_thread+0x4ad/0xb40
[ 26.578283] kthread+0x34f/0x450
[ 26.578501] retfromfork+0x563/0x800
[ 26.578752] retfromfork_asm+0x1a/0x30
[ 26.579012]
[ 26.579124] Freed by task 237:
[ 26.579335] kasansavestack+0x24/0x50
[ 26.579596] kasansavetrack+0x14/0x30
[ 26.579855] kasansavefree_info+0x3a/0x60
[ 26.580131] __kasanslabfree+0x43/0x70
[ 26.580388] kfree+0x321/0x500
[ 26.580591] nvmensheadchrrelease+0x39/0x50
[ 26.580883] __fput+0x352/0xa70
[ 26.581095] fputclosesync+0xd8/0x190
[ 26.581350] __x64sysclose+0x79/0xd0
[ 26.581595] dosyscall64+0x117/0x6b0
[ 26.581842] entry_SYSCAL
---truncated---
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching QEMU.
In the Linux kernel, the following vulnerability has been resolved:
vt: skip screen update for DEC alignment test on backgroup consoles
[BUG]
Recently, we encountered a KASAN warning as follows:
BUG: KASAN: slab-out-of-bounds in fbpadaligned_buffer+0x11f/0x140
Read of size 1 at addr ff1100015fd9f6a4 by task ttyfbconoob/1239
CPU: 7 UID: 0 PID: 1239 Comm: ttyfbconoob Not tainted 7.3.0-rc1 #100 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014
Call Trace:
<TASK>
...
kasan_report+0xf0/0x120
fbpadaligned_buffer+0x11f/0x140
ccw_putcs+0x86c/0xa80
fbcon_putcs+0x338/0x410
doupdateregion+0x21d/0x450
doconwrite+0x1e0e/0x4880
con_write+0x13/0x80
nttywrite+0x374/0x1010
filettywrite.isra.0+0x404/0x7a0
...
reproduce:
1) open /dev/tty0, set a KDFONTOP ioctl with op.op = KDFONTOP_SET,
op.width = 8 and op.height = 16 (visible VC1)
2) open /dev/tty1, set a KDFONTOP ioctl with op.op = KDFONTOP_SET,
op.width = 28 and op.height = 24 (invisible VC2)
3) echo 3 > /sys/devices/virtual/graphics/fbcon/rotate_all
4) write EShash8(esc hash8) to tty1
[CAUSE]
All VCs render to the framebuffer. setfont only modifies the target VC's
font without resizing the framebuffer backing buffer (par->rotated.buf);
the buffer is only resized for the visible VC
(fbcondosetfont -> ... -> vcdoresize -> updatescreen). This relies on
the conshouldupdate() check performed before every update_region().
However, the ESC # 8 path (docontrol -> doupdateregion) omits the
conshouldupdate() check. After changing the font size of an invisible VC,
doupdateregion() fills using the new font size against a buffer that was
never resized, causing an out-of-bounds access.
[FIX]
Only push the update when the console is visible and not blanked, add
the conshouldupdate() check in the docontrol() like every other call
site of doupdateregion() (updateregion(), invertscreen(), ...).
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching QEMU.
In the Linux kernel, the following vulnerability has been resolved:
tpm: Disable TPM on null key name mismatch
The null key name check exists to protect against TPM reset attacks, so
a mismatch should stop the device from serving further requests.
Currently it does not disable the chip when it finds a mismatch.
The mismatch is logged:
tpm tpm0: null key integrity check failed
but the chip keeps serving commands:
/ # tpm2_getcap -c properties-fixed
TPMPTFAMILY_INDICATOR:
as UINT32: 0x08322e3000
as string: "2.0"
...
tpm2loadnull() where the null key name check is run sets the chip as
disabled only if the rc is non zero. When the mismatch is seen, rc is
zero at that point and it returns success. The other issue is that the
caller expects the null key handle to be populated when the function
returns 0 which it does here without writing the handle and proceeds
assuming the null key handle is valid.
During the test, I noticed that tpm2startauth_session() uses the
uninitialized stack value as the key handle since tpm2loadnull()
returns 0 despite the integrity failure and proceeds with
TPM2CCSTARTAUTHSESS with this value as salt key handle.
Set rc to -ENODEV on the mismatch. The error path then disables the chip
and returns the correct code to the caller.
Tested in QEMU with swtpm and CONFIGTCGTPM2_HMAC=y by making
TPM2CCCONTEXTLOAD fail with TPM2RC_INTEGRITY and changing the name
of the re-created null key. The chip is now disabled on the mismatch.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: PPC: Book3S HV: fix secure device page leak on uvpagein() failure
In kvmppcsvmpagein(), if uvpage_in() fails after
kvmppcuvmemget_page() has succeeded, the secure device page is never
released. kvmppcuvmemgetpage() sets a bit in kvmppcuvmem_bitmap,
allocates a kvmppcuvmempage_pvt struct, marks the GFN as
KVMPPCGFNUVMEMPFN, and calls zonedevicepageinit() which sets
refcount=1 and locks the page. The subsequent goto out_finalize skips
the *mig.dst assignment, so migratevmafinalize() is a no-op for the
page, and none of those resources are ever reclaimed.
Each occurrence permanently consumes one entry from the firmware-bounded
secure memory pool (kvmppcuvmembitmap), leaks pvt, and leaves the GFN
marked as secure — making it unusable for the lifetime of the VM.
The twin __kvmppcsvmpageout() already handles the analogous uvpage_out()
failure correctly with unlock_page(dpage); __free_page(dpage). Apply
the same pattern here: unlockpage() followed by putpage(), which
chains through freezonedevicefolio() into kvmppcuvmemfoliofree()
to clear the bitmap bit, free pvt, and reset the GFN state.
Reachable whenever uvpagein() returns an error (e.g. UV pool
exhaustion) on any POWER9/10 + Ultravisor/PEF system.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: nv: Delay freeing of shadow S2 structures until VM destruction
We free the shadow S2 structures from kvmarchflushshadowall(), which
is a Bad Idea(tm). Freeing the page tables is fair game (this is what
this callback is for), but freeing the container that could still be
referenced by another part of the system is not great.
Instead, grow separate destructors that gets called when we tear the VM
down for good. From there, we can nuke both the individual MMUs as well
as the global array that points to them, safe in the knowledge that the
vcpus themselves have been destroyed already.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
RISC-V: KVM: Synchronize hrtimer callback during teardown
The non-Sstc hrtimer callback clears next_set before its final uses of
the enclosing vCPU. If teardown observes next_set as false while the
callback is still running, kvmriscvvcputimercancel() skips
hrtimercancel() and kvmdestroy_vcpus() can free the vCPU before the
callback enters kvmriscvvcpusetinterrupt().
A guest can arm the timer with SBI TIME and request shutdown with SBI
legacy shutdown or SRST. A VMM that honors KVMEXITSYSTEM_EVENT and
destroys the VM supplies the teardown side of the race; no post-launch
host ioctl is needed to arm or request teardown.
On upstream master 62cc90241548, generic KASAN reported:
BUG: KASAN: slab-use-after-free in dorawspin_lock
Write of size 4 at addr ff60000005e58898
kvmriscvvcpusetinterrupt
kvmriscvvcpuhrtimerexpired
__hrtimerrunqueues
hrtimer_interrupt
The object was allocated by KVMCREATEVCPU and freed concurrently by:
kvmdestroyvcpus
kvmarchdestroy_vm
kvmdestroyvm
__fput
For deterministic validation, I added mdelay(1000) immediately after
the existing next_set = false assignment. This only widens the
existing post-clear callback window. A no-delay trace build naturally
reached the callback-after-teardown-start/before-deinit ordering in 12
of 200 runs, but 1,500 stock-kernel stress iterations did not produce a
KASAN report, so natural reproduction is timing-sensitive.
Always invoke hrtimer_cancel() for an initialized timer. Preserve the
existing -EINVAL result when the timer is no longer set, but only after
synchronizing with a running callback.
With this patch, hrtimer_cancel() blocked for the full widened callback
window before vCPU destruction. KASAN reported no error in 100
fixed-and-widened runs or 200 fix-only timing-sweep runs.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
RISC-V: KVM: Serialize IMSIC attributes with vCPU migration
KVM device ioctls are not serialized against KVM_RUN. As a result,
kvmriscvaiaimsicrw_attr() can snapshot the physical CPU and HGEI of
an IMSIC VS-file before a concurrent vCPU migration releases it.
The HGEI can then be allocated to another vCPU before imsicvsfilerw()
uses the stale tuple. A GET or SET attribute may consequently access the
new owner's interrupt file.
Serialize the entire IMSIC attribute operation with the target vCPU
mutex. This prevents the VS-file from being migrated and recycled until
the attribute access completes. Acquire the mutex killably so that the
device ioctl remains interruptible while waiting for KVM_RUN to finish.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Transfer the hyp stack pages out of the host stage-2
fixhostownership() walks only the linear-map alias of each memblock
region, and the per-CPU hyp stack, mapped in the private VA range for
its guard page, has none.
Walk each stack's VA range with the same walker.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: nv: Fix null ptr deref on nested wp/unmap, teardown race
Commit 7270cc9157f4 ("KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU
notifiers") introduced VNCREL2 invalidation in both kvmnesteds2unmap()
and kvmnesteds2_wp().
However at the point of this being performed concurrent stage 2 teardown of
a nested guest can cause kvm->arch.mmu.pgt to be set to NULL.
This happens in kvmflushshadowall() -> kvmarchflushshadow_all() ->
kvmfreestage2pgd() and is performed under the kvm->mmulock.
Commit ec14c272408a ("KVM: arm64: nv: Unmap/flush shadow stage 2 page
tables") introduced the teardown of the entire nested MMU range, which then
invokes stage2applyrange() with resched=true:
mmunotifierinvalidaterangestart()
-> ... -> kvmmmunotifierinvalidaterange_start()
-> kvmmmuunmapgfnrange()
-> kvmunmapgfn_range()
-> kvmnesteds2_unmap()
-> kvmstage2unmap_range()
-> __unmapstage2range()
-> stage2applyrange()
This means that stage2applyrange() can drop the kvm->mmu_lock and thus
concurrent progress can be made in lockstep with
kvmarchflushshadowall().
If kvmarchflushshadowall() advances ahead of stage2applyrange() and
completes its operation it guarantees a NULL pointer deref.
Since kvmfreestage2pgd() is performed under the kvm->mmulock this will
either be observed NULL or not and serialised against
kvmfreestage2_pgd().
Resolve the issue by abstracting the invalidation to a new function,
kvminvalidatevncripaall(), and check that the pgt is non-NULL before
dereferencing it.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Fix spurious warning for benign stage 2 teardown race
kvmtool was used to establish an L1 guest with 8 CPUs and 8 GiB of RAM, an
L2 guest with 4 CPUs and 4 GiB of RAM and an L3 guest with 2 CPUs and 2 GiB
of RAM, all of which was then exited.
Under memory pressure in the L0 host warnings were observed due to
migration triggered by compaction:
WARNING: arch/arm64/kvm/mmu.c:336 at __unmapstage2range+0x64/0x80,
CPU#5: kcompactd0/66
Which was, in turn, triggered by an MMU notifier for the host invalidation:
mmunotifierinvalidaterangestart()
-> ... -> kvmmmunotifierinvalidaterange_start()
-> kvmmmuunmapgfnrange()
-> kvmunmapgfn_range()
-> kvmnesteds2_unmap()
-> kvmstage2unmap_range()
-> __unmapstage2range()
-> stage2applyrange()
<- -EINVAL, triggering a WARN_ON()
Racing with L0's teardown of stage 2 page tables:
exit_mm()
-> mmput()
-> __mmput()
-> exit_mmap()
-> mmunotifierrelease()
-> ... -> kvmmmunotifier_release()
-> kvmflushshadow_all()
-> kvmarchflushshadowall()
-> kvmfreestage2_pgd()
-> [ acquire kvm->mmu_lock for write ]
-> mmu->pgt = NULL [ among other tasks ]
-> [ release kvm->mmu_lock for write ]
It turns out there is a benign race resulting in a spurious warning:
Thread A - notify: migration | Thread B - notify: release
-------------------------------|---------------------------------
< kvm->mmu_lock held > |
stage2applyrange() |
get mmu->pgt, check !NULL |
... | kvmarchflushshadowall()
condreschedrwlockwrite(); | < contend, sleep kvm->mmulock >
< drop kvm->mmulock > | < acquire kvm->mmulock>
| ...
| kvmfreestage2_pgd()
| mmu->pgt = NULL
| < invalidate MMU >
| ...
| < release kvm->mmu_lock >
[ scheduled ] |
stage2applyrange() |
< loop to next > |
get, mmu->pgt, check !NULL |
is NULL, return -EINVAL |
__unmapstage2range() |
WARN_ON(-EINVAL) <--- entirely spurious - the race was handled
correctly.
Fix the spurious warning by updating stage2applyrange() to no longer
treat concurrent PGT teardown on lock release as an error - whether the
walker is tearing down page tables or doing something else this is a
legitimate reason to abort the operation without error.
This keeps the warning in place for all other circumstances.
In practice only __unmapstage2range() actually does anything with the
error so this only impacts that.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Fix AArch32 DBGBXVR<n> handling
The consolidation of the breakpoint and watchpoint register accessors
switched DBGBXVR<n> from trapbvr() to trapdbgwbreg(). The latter
selects backing storage with demuxwbreg(), which only handles Op2 values
4 through 7. Since DBGBXVR<n> uses Op2 1, an AArch32 guest access hits
KVMBUGON() and marks the VM dead.
DBGBXVR<n> aliases DBGBVR<n>_EL1[63:32], and its AA32(HI) descriptor
already selects the upper half. Map Op2 1 to dbg_bvr[] alongside Op2 4,
restoring the pre-regression behavior.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Don't WARN on an unknown VM ioctl in protected mode
kvmpkvmioctlallowed() WARNs when kvmgetcapforkvmioctl() doesn't
find the ioctl number in vmioctlcaps[], and kvmarchvm_ioctl() calls
it for every number the generic code doesn't handle, so
ioctl(vm_fd, 0xdeadbeef) from userspace taints a pKVM host and panics it
under paniconwarn. The lookup is fed userspace input: return false,
and userspace gets the -EINVAL kvmarchvm_ioctl() returns for that
number on a host without pKVM.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: SEV: Do cache maintenance on the source VM during intra-host migration
Manually perform cache maintenance on the source VM during intra-host
migration to ensure no stale data is left in CPU caches after the VM is
destroyed. Because the source VM is "converted" to a non-SEV VM, KVM's
memory reclaim flows won't trigger cache maintenance, e.g. when all guest
memory is reclaimed in response to detaching from the mmu_notifier.
Note, relying on the destination VM to do cache maintenance isn't an option
as KVM doesn't require identical guest memory configurations, i.e. the
source VM may have access to memory that the destination VM does not.
Enforcing equivalent memory configurations is infeasible, as it would
require a deep comparison of memslots, e.g. to verify that not only are
the memslot identical, but what the memslots point at is also identical.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: SEV: Free haveruncpus during VM destruction even if VM is no longer SEV
Unconditionally free SEV's "have run CPUs" cpumask in the VM destroy path,
i.e. even for what appear to be non-SEV VMs, as an SEV VM becomes a non-SEV
VM if its state is intra-host migrated. Alternatively, the mask could be
freed in sevmigratefrom() when "converting" the source VM, but that gets
annoying because ideally KVM would nullify the mask to guard against UAF,
and nullifying the mask would need be conditioned on CPUMASK_OFFSTACK=y.
Freeing the mask during sevmigratefrom() is also not robust against other
KVM bugs, though that's kind of a moot point since any such bugs would show
up even if sev->active is never set. I.e. KVM must get that side of things
correct. But, that's not a great reason to add more code just to make
things marginally less robust.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
s390/vfio-ap: fix KVM GISC and page leak when queue removed from host config
Three related problems exist in the handling of KVM interrupt and page
resources when a queue is removed from the host's AP configuration
while assigned to a mediated device (mdev).
Problem 1:
~~~~~~~~~
APRESPONSEQNOTAVAIL not handled in vfioapmdevresetqueue()
When the AP bus removes a queue device whose adapter or domain has
been removed from the host's AP configuration,
vfioapmdevremovequeue() is called. If the queue is still in the
host's AP configuration at that point, it calls
vfioapmdevresetqueue(), which issues a PQAP(ZAPQ). Since the
adapter is already gone from the host configuration, ap_zapq() returns
APRESPONSEQNOTAVAIL (0x01). This response code is not handled in
vfioapmdevresetqueue()'s switch statement and falls through to
the default case, which issues a WARN but does not call
vfioapfreeaqicresources(). As a result, if IRQ handling was
enabled for the queue by the guest, the KVM GISC registration and
the pinned guest page holding the notification indicator byte (NIB)
are both leaked.
This is fixed by adding APRESPONSEQNOTAVAIL to the same case as
APRESPONSEDECONFIGURED and APRESPONSECHECKSTOPPED in
vfioapmdevresetqueue(). Like those response codes, QNOTAVAIL
indicates the queue is not operational and no further reset attempts
are possible; the correct action is to free the IRQ resources
immediately.
Problem 2:
~~~~~~~~~
APRESPONSEQNOTAVAIL not handled in apqstatuscheck()
In vfioapmdevresetqueue(), there are four cases that indicate a queue
reset has not yet completed, in which case apqresetcheck() is queued to
a work queue to verify completion of the reset operation. This function
uses the PQAP(TAPQ) function to get the queue's status and calls
apqstatuscheck() to verify whether the reset has completed, failed or
needs to be executed again. As described in Problem #1 above,
apqresetcheck() does not specifically check for APRESPONSEQNOTAVAIL,
thereby potentially leaking KVM GISC registration and the pinned guest page
holding the NIB.
This is fixed by adding a case statement for APRESPONSEQNOTAVAIL to
apqstatuscheck() and returning -ENODEV for that case. The caller,
apqresetcheck() will then check for this return code and call
vfioapfreeaqicresources() to prevent the leak.
Problem 3:
~~~~~~~~~
vfioapfreeaqicresources() leaks saved_isc when kvm is NULL
vfioapfreeaqicresources() guards the call to
kvms390gisc_unregister() with:
if (q->savedisc != VFIOAPISCINVALID &&
!WARNON(!(q->matrixmdev && q->matrix_mdev->kvm)))
If matrix_mdev->kvm is NULL -- which can happen when
vfioapmdevunsetkvm() has already run and cleared kvm before a
subsequent cleanup path reaches this function -- the WARN_ON fires
and the entire block is skipped. This leaves q->saved_isc set to a
non-invalid value, creating a potential double-free on any subsequent
call to this function.
When kvm is NULL the KVM guest is already torn down, so
kvms390gisc_unregister() need not and cannot be called; however,
q->saved_isc must always be cleared. Fix this by separating the
kvms390giscunregister() call from the q->savedisc reset. The
WARNON now guards only the genuinely impossible case of matrixmdev
being NULL. A NULL kvm is handled gracefully by skipping only the
unregister call, and q->savedisc = VFIOAPISCINVALID is set
unconditionally whenever saved_isc was not already invalid.
Additionally, add an else clause to the host-config check in
vfioapmdevremovequeue() to call vfioapfreeaqicresources()
directly when the queue is not in the host's AP configuration. This
serves as a backstop: when the AP bus fires the driver .remove
callback after an adapter is removed from the host config, the queue
is by definition no longer addressable, so vfioapmdevresetqueue
---truncated---
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: fix use-after-free and multi-container gap in kfddevmapping
kfddevmapping caches the address_space of the first /dev/kfd opener
so that the GPU reset path can call unmapmappingrange() to zap all
userspace mappings of doorbell and MMIO ranges. This design has two
bugs that both manifest under SRIOV with multiple containers:
inode owned by the first opener's container. When that container
exits and its inode is released, kfddevmapping becomes a dangling
pointer. A subsequent GPU reset dereferences it inside
unmapmappingrange(), which takes immaprwsem on the freed inode,
causing a hard hang observable as an uninterruptible rwsem wait.
VMAs created by later openers live in a different address_space and
are never reached by unmapmappingrange(). After a GPU reset those
stale mappings keep doorbell and MMIO pages accessible to guest
userspace with no GPU behind them, risking PCIe transaction timeouts
and NMI panics.
Fix both bugs with the same approach used by DRM core (drm_drv.c):
create a private pseudo-filesystem at module init time and allocate one
anonymous inode from it. In kfd_open() redirect every opener's
file->fmapping to that inode's addressspace. The inode is
module-owned, lives exactly as long as the amdgpu module, and collects
VMAs from all openers in one address_space. A single
unmapmappingrange() call in the reset path then correctly reaches
every container's mappings with no dangling pointer risk.
The hang manifests as an NMI backtrace on the GPU reset workqueue stuck
spinning in rwsemdownreadslowpath() with a corrupted immap_rwsem:
Workqueue: amdgpu-reset-dev xgpuaimailboxflrwork [amdgpu]
Call Trace:
<TASK>
kvm_wait+0x1f/0x40
__pvqueuedspinlockslowpath+0x31d/0x3a0
rawspinlockirq+0x51/0x80
rwsemdownread_slowpath+0xb3/0x550
down_read+0x48/0xd0
unmapmappingrange+0x71/0x140
kfddevunmapmappingrange+0x5b/0x140 [amdgpu]
amdgpuamdkfdclearkfdmapping+0xd8/0x190 [amdgpu]
amdgpudevicegpu_recover+0x232/0x450 [amdgpu]
xgpuaimailboxflrwork+0xb5/0xc0 [amdgpu]
processonework+0x18e/0x3e0
worker_thread+0x2e3/0x420
kthread+0x10a/0x230
(cherry picked from commit 1128b4a52de1572e87431de837fd9850cb99542c)
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Do not clear VM-wide SVE feature on vCPU init failure
pkvmvcpuinitsve() clears KVMARMVCPUSVE in kvm->arch.vcpu_features
when it fails, but vcpuhassve() tests KVMARCHFLAGGUESTHAS_SVE,
which is left set. Later vCPUs on that VM then skip the SVE setup and
register with a NULL sve_state, which the guest's first FP access hands
to sveloadstate().
Return the error without touching vcpu_features.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Validate the SVE vector length in pkvmvcpuinit_sve()
pkvmvcpuinit_sve() clamps only the upper bound of the host-provided
svemaxvl, so an invalid vector length reaches svestatesizefromvl()
and the WARN_ON() there, which is fatal at EL2. The existing
!svestatesize test rejects such a length, but only after the macro has
run.
Check svevlvalid() before deriving the state size. A valid length
cannot yield a zero size, so the !svestatesize test goes with it.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: riscv: Fix NACL hfence entry update order
The SBI v3.0 specification (section 15.1.2) requires a nested HFENCE
entry to be populated as follows:
1) find an unused entry with Config.Pending == 0
2) update the PageNumber and PageCount words
3) update the Config word with Config.Pending set
__kvmriscvnacl_hfence() writes the Config word first, so the SBI
implementation (or NACL hardware) can observe a pending entry with
pnum/pcount values left over from the previous use of that entry,
resulting in incorrect TLB flush ranges.
Write pnum and pcount first and the Config word last. Since the
consumer is an external agent on coherent shared memory, use
WRITE_ONCE() to stop the compiler from reordering the stores and
smp_wmb() to make the parameter words globally visible before the
Pending bit is set.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Fix race in destroypages_crste()
Use READONCE() in destroypagescrste() to read the crste, avoid
dereferencing the pointer multiple times.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Fix potential races in dat skey functions
When datcondsetstoragekey() finds a large page, it will
conditionally set the storage key in absolute memory using
largecrsteto_phys() to get the absolute address.
There is a race window between datentrywalk() and
largecrsteto_phys(): the large page could have been split
concurrently, and largecrsteto_phys() might be called with a crste
that does not designate a large page, leading to crashes.
Similar issues were also present in datsetstorage_key().
datgetstoragekey() and datresetreferencebit() did instead check
for a potential concurrent splitting of the large page, but then
handled it incorrectly.
Fix by performing a READ_ONCE on the crste pointer, checking and using
the result, instead of dereferencing the pointer again. In case a race
is detacted, try datentrywalk() again.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Properly handle NULL pointer in datcondsetstoragekey()
Some callers pass NULL as oldkey. Calling pagecondsetstoragekey()
will cause that NULL pointer to get dereferenced.
Fix by checking for NULL and assigning the pointer to a dummy local
variable to avoid crashes.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Add missing srcu in kvms390setirqstate()
Like kvms390injectvcpu(), kvms390setirq_state() also needs the
kvm->srcu or the slots lock when performing the Store status operation.
Fix by taking kvm->srcu in kvms390setirqstate().
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Fix gaccessshadow_fault()
In some circumstances, it is possible that the page of nested guest
memory that is being shadowed is not present at all in the parent guest
gmap. datentrywalk() will not find any leaf entry and return with
-ENOENT, which will erroneously be propagated all the way to userspace.
Fix by manually calling gmap_link() on the memory of the nested guest
that is being shadowed if the mapping was not already present.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: vgic: Take a refcount on IRQs referenced by lastlrirq
Referencing the last interrupt inserted in an LR is rather fragile, as
this interrupt can vanish if a concurrently unmapped LPI.
Solve this by bumping up the refcount on the interrupt when populating
lastlrirq, and drop it at vgicpruneap_list() time, when LPIs are
being reclaimed.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Apply the fine-grained UNDEFs without FEAT_FGT
FGUs don't actually require hardware support, so don't gate fgt trap
config insertion on FGT. This is the only action required to allow FGUs
always, as kvmcalculatetraps() already computes the FGU bits with or
without FEAT_FGT.
This also fixes a spurious WARN when a TLBI OS is run on a guest in vEL1
without FEATTLBIOS on non FEATFGT hardware. In this configuration the
course-grained HCREL2.TTLBOS trap reaches the handler handletlbi_el1(),
which expects an EL1 TLBI only from vEL2. With FGUs enabled the UNDEF
will be injected without needing the specific handler.
[oliver: Take Wei-Lin's suggested changelog]
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Update control fields on #VMEXIT if and only if VMRUN succeeded
Leave control.erap_ctl and control.clean as-is in the VMCS if VMRUN fails,
because as per AMD:
there's no explicit architectural guarantee about the behavior in the
presence of VMRUN failures. So the best thing to do would be to assume
that if VMRUN fails, the actions requested in the control fields may not
have been performed.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Preserve TLB control (i.e. pending TLB flush) on failed VMRUN
Don't reset the VMCB's TLB control back to "do nothing" on a failed VMRUN,
as empirical testing shows that the CPU performs the requested TLB flush if
and only if VMRUN is successful, i.e. clearing TLB control on a failed
VMRUN effectively drops a TLB flush.
Explicitly track the need to flush all ASIDs on a per-CPU basis, as the
ASID reuse condition is tied to the pCPU, not to the vCPU. As a bonus,
this also obviates the need to avoid clobbering FLUSHALLASID with
TLBCONTROLFLUSHASID, e.g. in svmflushtlbasid().
Deliberately don't bother saving/restoring the "old" tlb_ctl on failure,
in quotes because it's not exactly the old tlbctl, it's the tlbctl from
after presvmrun(), but before updating tlbctl for flushall_asids. If
VMRUN fails and TLBCONTROLFLUSHALLASID is forced, then the next
successful run of the VMCB may unnecessarily flush all ASIDs, which
strictly speaking could result in noisy neighbor issues. However, the
fact that new_asid() is already guest-triggerable, because of KVM's flawed
behavior of clearing the ASID on emulated INIT, means that a guest can
already trigger a flush of all ASIDs at roughly the same rate. And once
KVM stops clobbering the ASID on emulated INIT, or assigns a static ASID
to each vCPU, this flaw goes away.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Use the active VMCB's MSR bitmap when checking if MSR is intercepted
Use the MSR permission bitmap of the active VMCB instead of assuming that
KVM is always using vmcb02's bitmap when L2 is active, as KVM uses msrpm02
if and only if L1 wants to intercept MSR accesses, i.e. if and only if KVM
needs to merge msprm01 with msrpm12.
Don't bother tracking the virtual address of the bitmap that's being used,
as __va() is cheap on x86, and caching the virtual address would introduce
yet another source of potentially stale information.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: SEV: Do cache maintenance on the source VM before clearing SEV state
Explicitly flush caches after intra-host migration before clearing "SEV
active" on the source VM, as doing cache maintenance afterwards creates a
tiny window where memory reclaim could return memory to the host without
performing a cache flush, e.g. as pointed out by Sashiko:
CPU1 in sevmigratefrom():
src->active = false;
CPU2 running concurrent unmap:
Since active is false, the automatic cache flush in
sevguestmemory_reclaimed is skipped.
The host frees and reallocates the page.
CPU1 in sevmigratefrom():
sevwritebackcaches(src_kvm);
Executes a hardware cache flush (wbnoinvd), which writes the guest's old
dirty ciphertext over the new page owner's data.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: SEV: Nullify "have run CPUs" mask pointer when freeing it
Nullify haveruncpus when freeing the mask, particularly in the error path
of __sevguestinit(), so that KVM doesn't have to subtly use sev->active
to track whether or not the mask has been freed. As pointed out by Sashiko,
blindly freeing the mask in sevvmdestroy() results in a double-free if
the mask is freed if __sevguestinit() fails.
Throw the logic in a helper as nullifying the pointer is frustratingly
difficult and weird due to haveruncpus being a single-entry array when
CPUMASKOFFSTACK=n. Deliberately don't use CPUMASKVAR_NULL, as it's not
directly assignable when the cpumask is on-stack, e.g. requires using a
local variable and a memcpy(), which is beyond ridiculous. Furthermore,
while clearing the on-stack bitmask is an unnecessary and arguably unwanted
side effect, KVM absolutely relies on '0' being the "null" value given that
the struct is zero-allocated.
Opportunistically add an alloc() helper to pair with free(); there are just
enough call sites to make doing so worthwhile.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: nVMX: Force MSR bitmap refresh if runtime eVMCS controls are modified
Force a refresh of the vmcs02 MSR bitmap during nested VM-Enter if the
runtime eVMCS controls (pin, primary, secondary, etc.) are being updated.
If L1 isn't intercepting TPR writes, runs L2 with TPR virtualization, and
then runs the same L2 with TPR virtualization disabled, KVM will fail to
refresh msr_bitmap02 and leave TPR in passthrough mode even though TPR
virtualization is disabled. I.e. failure to refresh the bitmap lets L2 (or
L1 by proxy) read and write L0's TPR.
References:
Virtualization/Hypervisors, published 2026-10-18
Flagged for matching KVM.
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Re-pend GETNESTEDSTATE_PAGES if getting said pages fails
Re-pend GETNESTEDSTATE_PAGES before exiting to userspace if getting the
nested pages fails in the KVM_RUN path. If userspace re-runs the vCPU, and
vmcs02 holds valid PFNs from the previous run of L2, then KVM could
re-enter L2 with stale, unpinned PFNs mapped into e.g. the vAPIC page.
Note, both SVM and VMX (as of commit 11722439fb20 ("KVM: nVMX: Ensure
KVMREQGETNESTEDSTATE_PAGES is cleared on VM-Exit") ensure the request
is cleared on VM-Exit (including the "forced" case), i.e. there is no risk
of double-mapping due to emulated VMLAUNCH/VMRESUME/VMRUN and the request
trying to map the nested pages.
References:
Operating Systems, Virtualization/Hypervisors, published 2026-10-18
Flagged for matching Proxmox VE, Ubuntu.
In the Linux kernel, the following vulnerability has been resolved:
net: atl1c: fix soft lockup on out-of-range tpd_cons read
The hardware can report an out-of-range tpd_cons (seen as 0xffff)
while the PCIe link/MAC is resetting. An out-of-range value can
never be reached and the loop below would spin forever. To avoid
a soft lockup treat it as "nothing new to clean" instead.
Reproduced on two machines, same NIC (Qualcomm Atheros AR8151 v2.0,
4-port), triggered by rebooting a Mikrotik CCR2004 PCIe card that
the ports are directly linked to:
precursor, before the lockup was captured with a full trace
elsewhere:
atl1c 0000:05:00.0 enp5s0f0: NETDEV WATCHDOG: CPU: 4: transmit queue 2 timed out 489984 ms
atl1c 0000:05:00.0: MAC state machine can't be idle since disabled for 10ms second
atl1c 0000:05:00.0: atl1c: enp5s0f0 NIC Link is Up<65535 Mbps Full Duplex>
65535 (0xffff) here is the same value tpd_cons reads back once the
loop below gets stuck.
caught by the soft lockup watchdog with a full stack trace:
watchdog: BUG: soft lockup - CPU#12 stuck for 354s! [napi/eth%d-0:329]
CPU: 12 UID: 0 PID: 329 Comm: napi/eth%d-0 Tainted: P O L 7.0.14-11-pve #1 PREEMPT(lazy)
RIP: 0010:atl1ccleantx+0x142/0x2d0 [atl1c]
Call Trace:
<TASK>
__napi_poll+0x32/0x1e0
napithreadedpoll_loop+0x286/0x2e0
napithreadedpoll+0xfd/0x140
kthread+0xf7/0x130
retfromfork+0x2da/0x3a0
retfromfork_asm+0x1a/0x30
</TASK>
References: