CVE-2025-38074: vhost-scsi: protect vq->log_used with vq->mutex
In the Linux kernel, the following vulnerability has been resolved:
vhost-scsi: protect vq->log_used with vq->mutex
The vhost-scsi completion path may access vq->log_base when vq->log_used is
already set to false.
vhost-thread QEMU-thread
vhost_scsi_complete_cmd_work()
-> vhost_add_used()
-> vhost_add_used_n()
if (unlikely(vq->log_used))
QEMU disables vq->log_used
via VHOST_SET_VRING_ADDR.
mutex_lock(&vq->mutex);
vq->log_used = false now!
mutex_unlock(&vq->mutex);
QEMU gfree(vq->log_base)
log_used()
-> log_write(vq->log_base)
Assuming the VMM is QEMU. The vq->log_base is from QEMU userpace and can be
reclaimed via gfree(). As a result, this causes invalid memory writes to
QEMU userspace.
The control queue path has the same issue.
Security readout for executives and security teams
Plain-English summary
A race condition in Linux vhost-scsi can make the kernel write through memory that QEMU has already released. On affected virtualization hosts, this could compromise the confidentiality, integrity, or availability of the QEMU process. The issue requires local, low-privileged access and specific vhost-scsi activity; it is not described as remotely exploitable.
Executive priority
Treat as a high-priority virtualization-host update, especially where untrusted or lower-privileged local users can access affected workloads. Patch through supported distribution channels after confirming vhost-scsi exposure. There is no supplied evidence of active exploitation, so prioritization should reflect configuration and local-access controls rather than CVSS alone.
Technical view
The vhost-scsi completion and control-queue paths can inspect vq->log_used without holding vq->mutex. Concurrent VHOST_SET_VRING_ADDR handling may disable logging and allow QEMU to free vq->log_base before log_write uses it, causing invalid writes into QEMU userspace. The published CVSS 3.1 score is 8.8 with local attack vector and changed scope.
Likely exposure
Exposure is most likely on Linux virtualization hosts using vhost-scsi with QEMU and affected kernel code. The source bundle does not establish that ordinary Linux systems, systems without vhost-scsi, or every listed kernel build are practically exposed. Distribution-specific kernel backports require vendor verification.
Exploitation context
The CVSS vector indicates local access, low privileges, low complexity, and no user interaction. KEV is false, and the supplied sources provide no evidence of active exploitation or a public exploit. Successful triggering depends on a concurrency race involving vhost-scsi logging and QEMU memory reclamation.
Researcher notes
The source bundle contains duplicated commit identifiers, an ambiguous version entry of "0," and affected-version data requiring distribution-specific interpretation. Seven stable-kernel commit references are supplied, but the bundle does not map each commit to a branch. Analysis should therefore avoid broad version-range claims and verify fixes against vendor kernel packages.
Mitigation direction
Apply the vendor-supported kernel update containing the applicable vhost-scsi synchronization fix.
Prioritize virtualization hosts actively using vhost-scsi with QEMU.
Review Linux distribution advisories for backported fixes and exact package versions.
If patching is delayed, consult vendor guidance for supported exposure-reduction measures.
Validation and detection
Inventory hosts using QEMU and determine whether vhost-scsi is enabled.
Map installed kernel packages to distribution advisories for CVE-2025-38074.
Verify the running kernel contains the applicable stable fix after reboot.
Confirm both completion-path and control-queue protections are included.
Recheck host exposure after kernel or virtualization configuration changes.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-38074 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
10Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.