CVE-2026-80932

The Linux kernel's virtio-vsock driver contains a use-after-free in which virtio_vsock_remove() flushes its workqueue items in the wrong order: send_pkt_work can queue rx_work after rx_work has already been flushed, so kfree(vsock) races with the still-pending rx_work, a bug confirmed by a KASAN slab-use-after-free report in virtio_transport_rx_work. The flaw is triggered when a virtio-vsock device is removed (hot-unplug or driver unbind) while transmit/receive work is in flight, a purely local race with no privileges or user interaction required per the CVSS vector. Successful exploitation of the race could allow a local attacker to corrupt freed kernel memory, plausibly yielding privilege escalation, information disclosure, or a denial of service (CVSS 3.1: 8.4, high). Any system running a kernel with the virtio_vsock driver is affected in principle, with real exposure concentrated in virtual machines and hosts that use virtio-vsock for guest-host communication (QEMU/KVM, Firecracker-style microVMs). The issue is resolved by flushing the work items in producer-to-consumer order (tx_work, then send_pkt_work, then rx_work); no public proof of concept or in-the-wild exploitation is known.

What to do: Apply a kernel update containing the fix (work items flushed in producer-to-consumer order: tx_work, then send_pkt_work, then rx_work) as soon as your distribution ships it. Until patched, avoid hot-unplugging or unbinding virtio-vsock devices (and avoid module removal) on hosts and guests where they are in active use, and consider blacklisting the virtio_vsock module on systems that do not need vsock. Watch kernel logs for KASAN 'slab-use-after-free in virtio_transport_rx_work' reports as an indicator of the race being hit.