CVE-2026-80932

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.