{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-74614",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-74614"
  ],
  "published": "2026-08-22T15:32:12Z",
  "summary": "vsock/virtio: read virtqueues under worker locks",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvsock/virtio: read virtqueues under worker locks\n\nCommit bd50c5dc182b (\"vsock/virtio: add support for device\nsuspend/resume\") made the *_run flags transition from false to true when\nrestore installs replacement virtqueues.  The RX, TX and event workers\nread their virtqueue before locking and checking the corresponding flag,\nso a worker delayed across freeze and restore can observe the replacement\nqueue's running state while retaining a pointer to the deleted queue.\n\nRead each virtqueue under its mutex after checking the run flag, keeping\nthe pointer and state in the same queue generation.",
  "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.183",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-74614"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/941329ce14c5f481223a10d1d4c8b57ea7f3048a"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/29dd10583bf9d2744cd84b862e4257c0a5699570"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/a1fb0c5b8a7c2753758aeced40971f99449dde0c"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/eae099c764c7ebdb842eb1f638913e310bdd6513"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/bd43a7ec668be428265b3209eb43647aedcf720a"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/1cecb4202afdbeddcf29d59baf596ac6ab753f7f"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/ebac8f6b1ef0e9278afe204b8692a7479988dace"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-25T05:42:41Z",
    "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 reached via AF_VSOCK sockets and virtio virtqueue completions, not via routable network protocols; per kernel CNA guidance vsock and virtio guest-driver bugs are scored Local even when the hypervisor is the peer.\nAC:L - An attacker or malicious host controls both sides of the race by flooding vsock/virtqueue traffic to queue RX/TX/event workers while virtio_vsock_freeze/restore deletes and replaces virtqueues, making the stale pre-lock virtqueue pointer race reliable and repeatable.\nPR:N - No guest privileges are required in the highest-impact scenario: a malicious hypervisor or host-initiated suspend/migrate triggers freeze/restore while virtio completions queue workers, matching confidential-computing models where the host is untrusted and holds no guest credentials.\nUI:N - Vulnerable RX/TX/event workers run automatically from virtqueue IRQ callbacks on a dedicated workqueue; no victim must mount filesystems, open files, or take deliberate action beyond normal virtio-vsock device operation and VM lifecycle events.\nS:U - Corruption is confined to the guest kernel virtio-vsock driver; exploited impact stays within the guest security boundary and does not cross to the hypervisor (guest-to-host escape would involve vhost-vsock on the host, not this guest-side driver).\nC:H - Use-after-free of a deleted virtqueue: virtqueue_disable_cb, virtqueue_get_buf, and virtqueue_enable_cb dereference freed vring_virtqueue slab memory, enabling attacker-controlled reuse and arbitrary kernel memory disclosure typical of virtio UAF bugs.\nI:H - Corrupted virtqueue metadata permits out-of-bounds ring/index manipulation and further virtqueue operations, furnishing heap corruption and arbitrary-write primitives suitable for guest ring-0 code execution and privilege escalation.\nA:H - Operating on freed virtqueues triggers KASAN slab-use-after-free and kernel BUG/oops/panic (as in the related virtio-vsock freeze bug CVE-2026-74613), fully denying guest availability even when full exploitation is not attempted."
    }
  }
}