CVE-2026-80932: vsock/virtio: flush works in dependency order
In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: flush works in dependency order
virtiovsockremove() stops the virtqueues and then flushes each work item before freeing the enclosing virtiovsock. The current order does not account for dependencies between those items: txwork may queue sendpktwork, and sendpktwork may queue rxwork.
In particular, sendpktwork can set restartrx and release txlock. The remove path can then stop the queues and flush rxwork before sendpktwork queues it. Although the later sendpktwork flush waits for that producer to finish, nothing waits for the newly queued rxwork, so kfree(vsock) can race with it.
KASAN reported:
BUG: KASAN: slab-use-after-free in virtiotransportrxwork+0x487/0x4b0 Read of size 8 at addr ffff888114c2b008 by task kworker/1:1/47 Workqueue: virtiovsock virtiotransportrxwork Call Trace: virtiotransportrxwork+0x487/0x4b0 processonework+0x688/0x1120 workerthread+0x45b/0xd10 Allocated by task 1: virtiovsockprobe+0xef/0x6b0 Freed by task 84: kfree+0x131/0x3c0 virtiovsockremove+0xd1/0x100
Flush the works in producer-to-consumer order. virtiovsockvqsdel() has already disabled the queue callbacks and cleared the run flags, so after txwork and sendpktwork are drained, no source remains that can queue rxwork after its flush.
Affected Software
Event History
Frequently Asked Questions
When does the use-after-free race occur?
The race occurs during removal of a virtio-vsock device, after its virtqueues have been stopped. A work item can queue dependent receive work after the remove path has already flushed that receive work and before the enclosing virtio_vsock object is freed.
What activity is required to trigger the vulnerable path?
The affected path requires virtio-vsock workqueue activity during device removal. Specifically, tx_work can queue send_pkt_work, and send_pkt_work can subsequently queue rx_work, creating the dependency that must be flushed in order.
How can an affected system be identified?
A manifestation may appear as a KASAN slab-use-after-free report in virtio_transport_rx_work running on the virtio_vsock workqueue. The report can show virtio_vsock_remove freeing the object while virtio_transport_rx_work accesses it.
What does the fix change?
The fix flushes the work items in producer-to-consumer dependency order. This ensures newly queued dependent receive work has completed before the virtio_vsock object is freed.