CVE-2026-80932
High · 8.4CVSS
8.4
EPSS
0.1%
Published
Sep 11, 2026
CISA due date
—
Cloudanix analysis
A bug in how the Linux kernel cleans up virtual socket connections can let a logged-in user crash the system or potentially take control of it.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Incorrect ordering of work item flushes in virtio_vsock_remove allows send_pkt_work to queue rx_work after the rx_work flush completes, resulting in a use-after-free when the newly scheduled rx_work accesses the already-freed virtio_vsock structure.
Why it matters to the business
Local attackers can trigger kernel memory corruption on systems using virtio-vsock, leading to crashes, denial of service, or potential privilege escalation; the 18-day-old flaw affects any Linux kernel build with virtio-vsock enabled and requires prompt patching to avoid service disruption.
How an attack unfolds
An attacker with local access triggers repeated vsock socket operations that schedule tx_work, send_pkt_work, and rx_work; concurrently invokes device removal or module unload to execute the flawed remove path, racing the final rx_work execution against kfree of the virtio_vsock object and causing the reported KASAN slab-use-after-free.
How to fix it
Upgrade to a kernel containing the corrected producer-to-consumer flush order in virtio_vsock_vqs_del and virtio_vsock_remove; rebuild and reboot all affected systems; no configuration workaround exists.
How to confirm the fix worked
Confirm the fix by inspecting the source for sequential tx_work then send_pkt_work then rx_work drains before kfree, or verify the absence of the KASAN report when exercising the remove path under load; test with vsock stress and module reload cycles.
Typical attack path
- Obtain local unprivileged shell on target host
- Create and exercise virtio-vsock connections to populate workqueues
- Trigger virtio_vsock_remove via module unload or hot-unplug
- Win the flush ordering race to access freed memory
- Escalate via corrupted kernel structures or cause DoS
How to detect it
Search kernel logs and KASAN reports for slab-use-after-free involving virtio_transport_rx_work or virtio_vsock_remove; inspect crash dumps for the exact call trace allocating in virtio_vsock_probe and freeing in virtio_vsock_remove.
What your security team should do
- Prioritize kernel updates on all systems exposing virtio-vsock (containers, VMs, hypervisors)
- Monitor for local privilege-escalation attempts targeting vsock workqueues
- Apply updates within standard change windows given the local attack vector and high CVSS
The record
In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: flush works in dependency order 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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|