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

CVE-2026-74613 Overview

CVE-2026-74613 is a use-after-free vulnerability in the Linux kernel's vsock/virtio transport. The flaw resides in the RX worker path, where the queue can be refilled after the virtqueues have already been deleted during device teardown. A prior fix (commit b917507e5ad9, "vsock/virtio: stop workers during the .remove()") routed the RX worker to a common exit when rx_run was clear, but that exit still refilled the RX queue when buffer counts were low. Work queued across virtio_vsock_vqs_del() can therefore add buffers to freed virtqueues, triggering a slab use-after-free detected by KASAN in virtqueue_add_sgs.

Critical Impact
A local attacker able to trigger device suspend, freeze, or removal races can cause kernel memory corruption leading to privilege escalation, denial of service, or full system compromise.

Affected Products

Linux kernel builds containing commit b917507e5ad9 ("vsock/virtio: stop workers during the .remove()") without the corresponding refill fix
Systems using the virtio_vsock transport, common in KVM/QEMU guests and cloud virtualization hosts
Multiple stable branches, as indicated by eight backport commits in git.kernel.org

Discovery Timeline

2026-08-22 - CVE-2026-74613 published to NVD
2026-08-25 - Last updated in NVD database

Technical Details for CVE-2026-74613

Vulnerability Analysis

The vulnerability is a use-after-free [CWE-416] in the virtio-vsock RX worker. The virtio_transport_rx_work function processes incoming vsock packets on a workqueue. When the transport is torn down, for example during PCI freeze or module removal, virtio_vsock_freeze() calls vp_del_vqs() which frees the underlying virtqueue structures.

Before that teardown, rx_run is cleared to signal workers to stop. However, the earlier patch made the worker jump to a common exit label whose logic still checks buffer counts and calls virtio_vsock_rx_fill() if replenishment is needed. That function invokes virtqueue_add_sgs() against a virtqueue that has already been freed by vp_del_vq(), producing the KASAN slab-use-after-free report shown in the advisory.

Root Cause

The root cause is incorrect exit routing in the RX worker teardown path. The worker distinguishes only between successful processing and error, not between running and shutting-down states. When rx_run is false, the code should skip refill entirely, but instead it falls through to the same replenishment logic used for a healthy queue. Concurrent freeing in virtio_vsock_freeze() and refill in the workqueue creates a race window in which freed memory is written.

Attack Vector

Exploitation requires local access and the ability to interact with virtio-vsock, or to induce a suspend, freeze, hibernate, or hot-unplug event that triggers the teardown path. An unprivileged user in a virtual machine can open vsock sockets and generate RX traffic while triggering power-management transitions. The resulting use-after-free write to slab memory can be shaped into kernel heap corruption. Consult the upstream fix and the stable backports for the exact code delta; no public proof-of-concept is currently available.

Detection Methods for CVE-2026-74613

Indicators of Compromise

KASAN reports referencing slab-use-after-free in virtqueue_add_sgs with call stacks including virtio_vsock_rx_fill and virtio_transport_rx_work.
Kernel panics or oopses on hosts and guests during suspend, hibernate, or virtio device removal cycles.
Unexpected virtio_vsock worker activity logged after virtio_vsock_freeze or vp_del_vqs events.

Detection Strategies

Enable KASAN on test and staging kernels to surface the exact use-after-free signature described in the advisory.
Correlate dmesg output for BUG: KASAN entries with power-management or PCI hot-plug events on the same host.
Monitor for repeated guest crashes on virtualization hosts that expose vsock, which can indicate exploitation attempts.

Monitoring Recommendations

Ship kernel logs from hypervisors and guests to a centralized data lake and alert on virtqueue_add_sgs, virtio_transport_rx_work, and KASAN strings.
Track suspend, resume, and device freeze counts per host to identify unusual patterns that may indicate deliberate race triggering.
Baseline crash frequency for VMs using vsock and alert on statistically significant increases after patching windows.

How to Mitigate CVE-2026-74613

Immediate Actions Required

Apply the upstream mainline fix from commit 1aa21e7c8702a7c37cd7d3cace1a652cfa5e8171 or the appropriate stable backport for your kernel branch.
Rebuild and redeploy custom kernels, then reboot affected hosts and guests to activate the patched RX worker exit path.
Prioritize hypervisors and multi-tenant hosts where local users can trigger vsock activity and power-management events.

Patch Information

The fix routes the RX worker to a no-refill exit when rx_run is clear, leaving the normal exit to replenish only a running queue. Mainline and stable backports are available: 1aa21e7, 38c7763, 4d37e35, 9d80a04, a309b74, a31e0ad, a7658508, and e82a5fa.

Workarounds

Unload the vmw_vsock_virtio_transport module on systems that do not require vsock functionality.
Blocklist vsock and related modules in /etc/modprobe.d/ on hosts where guest-to-host vsock is not needed.
Restrict local user access on virtualization hosts and disable non-essential suspend or hibernate paths until patched kernels are deployed.

bash

# Disable virtio-vsock transport until patched kernel is deployed
echo 'blacklist vmw_vsock_virtio_transport' | sudo tee /etc/modprobe.d/disable-vsock.conf
echo 'blacklist vmw_vsock_virtio_transport_common' | sudo tee -a /etc/modprobe.d/disable-vsock.conf
sudo rmmod vmw_vsock_virtio_transport 2>/dev/null
sudo update-initramfs -u

# Verify installed kernel version after patching
uname -r