CVE-2026-80932vsock/virtio: flush works in dependency order
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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.
- CVSS
- 8.4 HIGH (v3.1, CNA)CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Oct 16, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | from 0ea9e1d3a9e3ef7d2a1462d3de6b95131dc7d872 before e059a14c1067bcc4f7b1947cd09f2baab98e340f; from 0ea9e1d3a9e3ef7d2a1462d3de6b95131dc7d872 before 531e2ac2dab1ab90a16427c4f9c86663633e9487; from 0ea9e1d3a9e3ef7d2a1462d3de6b95131dc7d872 before f3313d952fc380cff53db9a28451a8807aa67b43; from 0ea9e1d3a9e3ef7d2a1462d3de6b95131dc7d872 before b9cb4e8ba71c9fbd935d66baa71bbb0b87192c94; from 0ea9e1d3a9e3ef7d2a1462d3de6b95131dc7d872 before 2187a56f2fd1715d54daed6392809223c60544f3; from 0ea9e1d3a9e3ef7d2a1462d3de6b95131dc7d872 before 165a330a68b5f299d8735f0194c314cb2e571269; from 0ea9e1d3a9e3ef7d2a1462d3de6b95131dc7d872 before da5e9f08714c19ba04e6863aca69d40f042f2e04; from 0ea9e1d3a9e3ef7d2a1462d3de6b95131dc7d872 before 728836ebca239810f164262b10211ef59182f811 | CNA record |
References
- https://git.kernel.org/stable/c/e059a14c1067bcc4f7b1947cd09f2baab98e340f
- https://git.kernel.org/stable/c/531e2ac2dab1ab90a16427c4f9c86663633e9487
- https://git.kernel.org/stable/c/f3313d952fc380cff53db9a28451a8807aa67b43
- https://git.kernel.org/stable/c/b9cb4e8ba71c9fbd935d66baa71bbb0b87192c94
- https://git.kernel.org/stable/c/2187a56f2fd1715d54daed6392809223c60544f3
- https://git.kernel.org/stable/c/165a330a68b5f299d8735f0194c314cb2e571269
- https://git.kernel.org/stable/c/da5e9f08714c19ba04e6863aca69d40f042f2e04
- https://git.kernel.org/stable/c/728836ebca239810f164262b10211ef59182f811
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.