Look up another CVE · open CVE-2026-80932 in the interactive tracker
CVE-2026-80932
vsock/virtio: flush works in dependency order
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem net/vmw_vsock. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-80932 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
virtio_vsock_remove() stops the virtqueues and then flushes each work item before freeing the enclosing virtio_vsock. The current order does not account for dependencies between those items: tx_work may queue send_pkt_work, and send_pkt_work may queue rx_work. In particular, send_pkt_work can set restart_rx and release tx_lock. The remove path can then stop the queues and flush rx_work before send_pkt_work queues it. Although the later send_pkt_work flush waits for that producer to finish, nothing waits for the newly queued rx_work, so kfree(vsock) can race with it. KASAN reported: BUG: KASAN: slab-use-after-free in virtio_transport_rx_work+0x487/0x4b0 Read of size 8 at addr ffff888114c2b008 by task kworker/1:1/47 Workqueue: virtio_vsock virtio_transport_rx_work Call Trace: virtio_transport_rx_work+0x487/0x4b0 process_one_work+0x688/0x1120 worker_thread+0x45b/0xd10 Allocated by task 1: virtio_vsock_probe+0xef/0x6b0 Freed by task 84: kfree+0x131/0x3c0 virtio_vsock_remove+0xd1/0x100 Flush the works in producer-to-consumer order. virtio_vsock_vqs_del() has already disabled the queue callbacks and cleared the run flags, so after tx_work and send_pkt_work are drained, no source remains that can queue rx_work after its flush.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/vmw_vsock/virtio_transport.c
- What this is
- VIRTIO AND VHOST VSOCK DRIVERMAINTAINERS section matched on net/vmw_vsock/virtio_transport.c · kvm@vger.kernel.org · Maintained
- Kernel module
- vmw_vsock_virtio_transport
Check it on the machine
grep -wE 'CONFIG_VIRTIO_VSOCKETS|CONFIG_VSOCKETS' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w vmw_vsock_virtio_transportPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sid, bookworm · linux-6.12m
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switches
- CONFIG_VIRTIO_VSOCKETS, CONFIG_VSOCKETS
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 8.4 high
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.14%, higher than 2.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/vmw_vsock
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.8 | 5.10.270 | e059a14c1067 |
| 4.8 | 5.15.221 | 531e2ac2dab1 |
| 4.8 | 6.1.188 | f3313d952fc3 |
| 4.8 | 6.6.157 | b9cb4e8ba71c |
| 4.8 | 6.12.109 | 2187a56f2fd1 |
| 4.8 | 6.18.50 | 165a330a68b5 |
| 4.8 | 7.2.4 | da5e9f08714c |
| 4.8 | 7.3 | 728836ebca23 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bug is in the guest virtio-vsock driver during virtio_vsock_remove(), reached via virtio device unplug and AF_VSOCK virtqueue completions rather than routed packets; kernel CNA guidance scores vsock and virtio guest-driver bugs as Local.
- AC:LAttack complexity, low
- A malicious hypervisor controls both sides of the race by injecting vsock packets that generate RST replies so send_pkt_work sets restart_rx and queues rx_work, while concurrently hot-unplugging the device so remove() flushes rx_work too early; the attacker can retry and pause guest vCPUs, so success is not an uncontrolled condition.
- PR:NPrivileges required, none
- No guest privileges are required: a malicious hypervisor or deprivileged VMM (Firecracker, crosvm, TDX/SEV-SNP) triggers device removal and virtqueue traffic with no guest credentials; host-sent packets to unbound ports generate reply skbs in kernel workqueues without any guest socket, user, or capability.
- UI:NUser interaction, none
- virtio_vsock_remove() and the racing send_pkt_work/rx_work items run from driver teardown and virtqueue IRQ workqueues; no guest user must mount a filesystem, open a device, or take any other action.
- S:UScope, unchanged
- The use-after-free corrupts the guest kernel virtio_vsock object and remains within the guest OS security authority; a guest-to-host escape would require a host vhost-vsock bug, not this guest-side remove path.
- C:HConfidentiality impact, high
- KASAN reports a slab use-after-free read in virtio_transport_rx_work of the kfree'd virtio_vsock; a workqueue callback running on a freed slab object enables attacker-controlled reuse and arbitrary kernel memory disclosure.
- I:HIntegrity impact, high
- After kfree(vsock), pending rx_work still runs against the freed object (rx_lock, vqs, flags); slab reuse of that work_struct yields arbitrary writes and control-flow hijack typical of kernel workqueue UAFs, not merely a crash.
- A:HAvailability impact, high
- The reported KASAN bug is a kernel slab-use-after-free in virtio_transport_rx_work during device removal, causing oops or panic and fully denying guest availability even without completing a privilege-escalation exploit.