CVE-2026-80932: Linux Kernel Use-After-Free Vulnerability

CVE-2026-80932 Overview

CVE-2026-80932 is a use-after-free vulnerability in the Linux kernel's vsock/virtio transport. The flaw resides in virtio_vsock_remove(), which flushes work items in an order that does not respect their producer-consumer dependencies. During device removal, send_pkt_work can queue rx_work after rx_work has already been flushed, causing the kernel to access freed memory when the enclosing virtio_vsock structure is released.

KASAN confirmed the issue with a slab-use-after-free report in virtio_transport_rx_work. A local attacker with the ability to trigger device removal can potentially exploit this race condition to corrupt kernel memory.

Critical Impact
A local attacker can trigger a race condition during virtio-vsock device removal to cause kernel memory corruption, leading to denial of service or potential local privilege escalation.

Affected Products

Linux kernel with vsock/virtio transport enabled
Distributions shipping affected stable kernel branches (patches issued across multiple stable trees)
Virtualization hosts and guests using VMware/KVM vsock communication over virtio

Discovery Timeline

2026-09-11 - CVE-2026-80932 published to the National Vulnerability Database (NVD)
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-80932

Vulnerability Analysis

The vulnerability is a use-after-free [CWE-416] triggered by a race condition [CWE-362] in the virtio vsock removal path. The virtio_vsock_remove() function stops the virtqueues and then flushes each work item before freeing the enclosing virtio_vsock structure. The existing flush order does not account for dependencies between work items.

Specifically, tx_work can queue send_pkt_work, and send_pkt_work can queue rx_work. Additionally, send_pkt_work sets restart_rx and releases tx_lock during execution. This creates a window where the removal path stops the queues, flushes rx_work, then flushes send_pkt_work. However, the concurrent send_pkt_work execution can queue a new rx_work after its own flush completes.

Because nothing waits for the newly queued rx_work, the subsequent kfree(vsock) executes while a worker thread is still accessing the structure. The KASAN report shows virtio_transport_rx_work+0x487/0x4b0 reading 8 bytes from freed memory allocated during virtio_vsock_probe().

Root Cause

The root cause is an incorrect ordering of work-item flushes relative to the producer-consumer chain (tx_work → send_pkt_work → rx_work). Flushing consumers before producers leaves a window where producers can re-queue consumer work after the consumer flush has completed, resulting in access to memory freed by virtio_vsock_remove().

Attack Vector

Exploitation requires local access to a system where an attacker can influence virtio-vsock device removal, such as through hotplug operations or hypervisor-triggered teardown. The race condition depends on precise timing between the removal thread and the worker threads processing pending virtio packets. A successful race yields a kernel-mode use-after-free that can be leveraged for denial of service or, with additional heap-shaping techniques, potentially for privilege escalation to kernel context.

No verified public exploit code is available. Refer to the upstream kernel commits linked below for the authoritative patch details rather than synthesized code.

Detection Methods for CVE-2026-80932

Indicators of Compromise

KASAN reports containing BUG: KASAN: slab-use-after-free in virtio_transport_rx_work
Kernel oops or panics referencing virtio_transport_rx_work, virtio_vsock_remove, or the virtio_vsock workqueue during device teardown
Unexpected reboots or process crashes on virtualization hosts or guests that use virtio-vsock following driver unload or VM lifecycle events

Detection Strategies

Enable CONFIG_KASAN on test and staging kernels to surface the exact use-after-free signature during QA
Monitor dmesg and journalctl -k for stack traces involving virtio_vsock workqueue functions
Correlate device removal or module unload events (virtio_vsock, vmw_vsock_virtio_transport) with subsequent kernel warnings

Monitoring Recommendations

Forward kernel logs to a centralized SIEM and alert on slab-use-after-free, KASAN, and virtio_vsock string matches
Track modprobe/rmmod activity and virtio device hotplug events on virtualization hosts
Baseline expected virtio_vsock module load/unload frequency to identify anomalous churn that could indicate exploitation attempts

How to Mitigate CVE-2026-80932

Immediate Actions Required

Apply the upstream Linux kernel patches referenced below to all affected stable branches
Prioritize patching virtualization hosts and multi-tenant systems where local users share kernels
If patching is not immediately possible, avoid unloading or hot-removing the virtio_vsock transport on production systems

Patch Information

The fix reorders the work-item flushes in virtio_vsock_remove() to drain in producer-to-consumer order. After virtio_vsock_vqs_del() disables the queue callbacks and clears the run flags, draining tx_work and send_pkt_work first ensures no source remains that can queue rx_work after its flush. The corrected sequence has been merged across multiple stable kernel trees:

Workarounds

Blacklist the vmw_vsock_virtio_transport and virtio_vsock modules on systems that do not require vsock functionality
Restrict local user access to reduce the attack surface for triggering the race condition
Avoid administrative operations that unload or hot-remove virtio-vsock devices until the kernel is patched

bash

# Prevent the vulnerable module from loading until patches are applied
echo "blacklist vmw_vsock_virtio_transport" | sudo tee /etc/modprobe.d/blacklist-vsock.conf
echo "blacklist virtio_vsock" | sudo tee -a /etc/modprobe.d/blacklist-vsock.conf
sudo update-initramfs -u

# Verify the module is not currently loaded
lsmod | grep -E 'virtio_vsock|vmw_vsock'