EUVD-2026-76255
GHSA-c7hj-cc73-472r
Severity by source
AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Local-only race condition (AC:H) requiring active vsock traffic and device removal timing; PR:L for basic VM/module access; primary impact is DoS (A:H) with limited memory exposure.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
6DescriptionCVE.org
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.
AnalysisAI
Slab-use-after-free in the Linux kernel vsock/virtio transport driver allows a local attacker to trigger kernel memory corruption by exploiting a work-item flush ordering bug during device removal. The virtio_vsock_remove() path flushes work items without respecting producer-to-consumer dependencies (tx_work → send_pkt_work → rx_work), allowing kfree(vsock) to race with a newly queued rx_work item, as confirmed by KASAN reporting a UAF read in virtio_transport_rx_work. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires: (1) the target kernel is compiled with CONFIG_VIRTIO_VSOCK enabled and the module is loaded; (2) a virtio-vsock device is present and actively processing packets (AF_VSOCK traffic in flight); (3) a concurrent virtio_vsock_remove() event occurs - triggered by device hotplug removal, VFIO device detach, or module unload - while work items are mid-execution. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The provided CVSS vector (AV:L/AC:L/PR:N/UI:N/C:H/I:H/A:H, score 8.4) significantly overstates real-world exploitability. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | Apply the vendor-released patches corresponding to your kernel stable branch: 6.12.109, 6.18.50, 7.2.4, or 7.3-rc1, sourced from git.kernel.org/stable. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours: identify all systems running affected Linux kernel versions (prior to 6.12.109, 6.18.50, 7.2.4, or 7.3) with vsock/virtio functionality enabled; verify via dmesg or lsmod for virtio_vsock module presence. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Share
External POC / Exploit Code
Leaving vuln.today