{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2025-38074",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2025-38074"
  ],
  "published": "2025-06-18T09:34:24Z",
  "summary": "vhost-scsi: protect vq->log_used with vq->mutex",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvhost-scsi: protect vq->log_used with vq->mutex\n\nThe vhost-scsi completion path may access vq->log_base when vq->log_used is\nalready set to false.\n\n    vhost-thread                       QEMU-thread\n\nvhost_scsi_complete_cmd_work()\n-> vhost_add_used()\n   -> vhost_add_used_n()\n      if (unlikely(vq->log_used))\n                                      QEMU disables vq->log_used\n                                      via VHOST_SET_VRING_ADDR.\n                                      mutex_lock(&vq->mutex);\n                                      vq->log_used = false now!\n                                      mutex_unlock(&vq->mutex);\n\n\t\t\t\t      QEMU gfree(vq->log_base)\n        log_used()\n        -> log_write(vq->log_base)\n\nAssuming the VMM is QEMU. The vq->log_base is from QEMU userpace and can be\nreclaimed via gfree(). As a result, this causes invalid memory writes to\nQEMU userspace.\n\nThe control queue path has the same issue.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/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.146",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-38074"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/80cf68489681c165ded460930e391b1eb37b5f6f"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/8312a1ccff1566f375191a89b9ba71b6eb48a8cd"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/59614c5acf6688f7af3c245d359082c0e9e53117"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/ca85c2d0db5f8309832be45858b960d933c2131c"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/bd8c9404e44adb9f6219c09b3409a61ab7ce3427"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/c0039e3afda29be469d29b3013d7f9bdee136834"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/f591cf9fce724e5075cc67488c43c6e39e8cbe27"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T12:19:11Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 8.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - vhost-scsi is a host-kernel backend driven by a guest VM through its virtqueues and by the VMM through /dev/vhost-scsi ioctls; there is no network-facing path, so the attacker acts from a local context (inside a guest on the host, or a local host process holding the vhost fd).\nAC:L - The attacker controls both sides of the race \u2014 a continuous stream of guest SCSI I/O keeps the unlocked completion worker running, and a guest-initiated virtio device reset forces QEMU's vhost_dev_stop() to clear log_used and free the log bitmap; the window is wide because the entire completion loop ran with no lock at all, and each command issues multiple log_write() calls.\nPR:L - The attacker needs to be an authorized guest tenant driving the virtio-scsi device (or a local host process with the vhost-scsi fd); no host root or elevated host capability is required, and ordinary unprivileged guest I/O suffices to keep the completion path armed.\nUI:N - No victim action is needed \u2014 the guest can itself force the log-teardown path via a virtio device reset or feature renegotiation while completions are in flight, and the migration-end teardown is a routine automated host operation, not a tricked user action.\nS:C - The vulnerable component is the host kernel's vhost-scsi driver, but the corrupted resource is the host VMM (QEMU) userspace address space, reached from inside a guest \u2014 the guest confinement boundary is crossed, matching the guest-to-host escape case.\nC:H - Guest-influenced bit-sets at attacker-chosen offsets from a stale log_base corrupt live QEMU heap objects (pointers, lengths, migration bitmap state), which is leverageable to disclose host memory back into the guest.\nI:H - This is an out-of-bounds/use-after-free write into the host VMM process with attacker-controlled offset and multiplicity, enabling corruption of QEMU control structures and hence control-flow hijack, and it silently corrupts the migration dirty bitmap so migrated guest state is written incorrectly.\nA:H - Corrupting glib heap metadata aborts QEMU and terminates the VM, migrations fail or complete with corrupt state, and set_bit_to_user()'s BUG_ON(r != 1) can be reached when the stale log page is no longer pinnable."
    }
  }
}