CVE-2025-38074

What it actually does

Race condition in vhost-scsi allows the completion path to dereference vq->log_base after vq->log_used is cleared and the backing QEMU memory is freed, resulting in invalid userspace memory writes from kernel context.

Why it matters to the business

Virtualization hosts running affected kernels face elevated risk of crashes, data corruption, or container/VM escape in environments using vhost-scsi, with urgency driven by the 496-day publication window and listed kernel privilege-escalation campaigns.

How an attack unfolds

An attacker controlling a guest or userspace process triggers concurrent vhost_scsi_complete_cmd_work and VHOST_SET_VRING_ADDR operations; the window allows log_write to a reclaimed QEMU allocation, enabling memory corruption that threat actors such as Advanced Spyware Campaign or Linux kernel privilege-escalation groups have chained in similar kernel flaws.

How to fix it

Upgrade the Linux kernel to commit 80cf68489681c165ded460930e391b1eb37b5f6f or later stable releases that serialize log_used access under vq->mutex; rebuild and reboot all affected hosts.

How to confirm the fix worked

Confirm the patch is present by checking for the mutex protection around log_used in vhost_add_used_n and vhost_scsi_complete_cmd_work; run targeted vhost-scsi stress tests under QEMU to verify no use-after-free occurs.

Typical attack path

1. Obtain code execution or guest access on a vhost-scsi backed VM
2. Race VHOST_SET_VRING_ADDR ioctl against in-flight completion work
3. Force gfree of log_base from QEMU side while kernel still holds reference
4. Trigger log_write to freed region to corrupt QEMU or kernel structures
5. Escalate to host privileges or cause denial of service

How to detect it

Review kernel logs for vhost-scsi oops or warnings around log_used and log_base; correlate with QEMU process crashes or abnormal VHOST_SET_VRING_ADDR calls from untrusted guests; inspect for unexpected memory corruption traces in dmesg after vhost activity.

What your security team should do

• Prioritize kernel updates on all virtualization hosts within 30 days given the long disclosure window
• Disable vhost-scsi where not required or isolate affected workloads behind additional controls
• Monitor for similar race patterns in other vhost subsystems
• Audit downstream distributions for backported fixes matching the referenced commit