{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-80932", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-80932" ], "published": "2026-09-11T19:47:07Z", "summary": "vsock/virtio: flush works in dependency order", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvsock/virtio: flush works in dependency order\n\nvirtio_vsock_remove() stops the virtqueues and then flushes each work\nitem before freeing the enclosing virtio_vsock. The current order does\nnot account for dependencies between those items: tx_work may queue\nsend_pkt_work, and send_pkt_work may queue rx_work.\n\nIn particular, send_pkt_work can set restart_rx and release tx_lock.\nThe remove path can then stop the queues and flush rx_work before\nsend_pkt_work queues it. Although the later send_pkt_work flush waits\nfor that producer to finish, nothing waits for the newly queued rx_work,\nso kfree(vsock) can race with it.\n\nKASAN reported:\n\n BUG: KASAN: slab-use-after-free in\n virtio_transport_rx_work+0x487/0x4b0\n Read of size 8 at addr ffff888114c2b008 by task kworker/1:1/47\n Workqueue: virtio_vsock virtio_transport_rx_work\n Call Trace:\n virtio_transport_rx_work+0x487/0x4b0\n process_one_work+0x688/0x1120\n worker_thread+0x45b/0xd10\n Allocated by task 1:\n virtio_vsock_probe+0xef/0x6b0\n Freed by task 84:\n kfree+0x131/0x3c0\n virtio_vsock_remove+0xd1/0x100\n\nFlush the works in producer-to-consumer order. virtio_vsock_vqs_del()\nhas already disabled the queue callbacks and cleared the run flags, so\nafter tx_work and send_pkt_work are drained, no source remains that can\nqueue rx_work after its flush.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.188", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-80932" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/e059a14c1067bcc4f7b1947cd09f2baab98e340f" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/531e2ac2dab1ab90a16427c4f9c86663633e9487" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/f3313d952fc380cff53db9a28451a8807aa67b43" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/b9cb4e8ba71c9fbd935d66baa71bbb0b87192c94" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/2187a56f2fd1715d54daed6392809223c60544f3" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/165a330a68b5f299d8735f0194c314cb2e571269" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/da5e9f08714c19ba04e6863aca69d40f042f2e04" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/728836ebca239810f164262b10211ef59182f811" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-09-14T12:06:03Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 8.4, "cvss_v3_severity": "High", "scenario": "AV:L - The bug is in the guest virtio-vsock driver during virtio_vsock_remove(), reached via virtio device unplug and AF_VSOCK virtqueue completions rather than routed packets; kernel CNA guidance scores vsock and virtio guest-driver bugs as Local.\nAC:L - A malicious hypervisor controls both sides of the race by injecting vsock packets that generate RST replies so send_pkt_work sets restart_rx and queues rx_work, while concurrently hot-unplugging the device so remove() flushes rx_work too early; the attacker can retry and pause guest vCPUs, so success is not an uncontrolled condition.\nPR:N - No guest privileges are required: a malicious hypervisor or deprivileged VMM (Firecracker, crosvm, TDX/SEV-SNP) triggers device removal and virtqueue traffic with no guest credentials; host-sent packets to unbound ports generate reply skbs in kernel workqueues without any guest socket, user, or capability.\nUI:N - virtio_vsock_remove() and the racing send_pkt_work/rx_work items run from driver teardown and virtqueue IRQ workqueues; no guest user must mount a filesystem, open a device, or take any other action.\nS:U - The use-after-free corrupts the guest kernel virtio_vsock object and remains within the guest OS security authority; a guest-to-host escape would require a host vhost-vsock bug, not this guest-side remove path.\nC:H - KASAN reports a slab use-after-free read in virtio_transport_rx_work of the kfree'd virtio_vsock; a workqueue callback running on a freed slab object enables attacker-controlled reuse and arbitrary kernel memory disclosure.\nI:H - After kfree(vsock), pending rx_work still runs against the freed object (rx_lock, vqs, flags); slab reuse of that work_struct yields arbitrary writes and control-flow hijack typical of kernel workqueue UAFs, not merely a crash.\nA:H - The reported KASAN bug is a kernel slab-use-after-free in virtio_transport_rx_work during device removal, causing oops or panic and fully denying guest availability even without completing a privilege-escalation exploit." } } }