GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux vhost-scsi: stale response iovecs after a memory-table change write into unrelated memory

CVSS 7.8CVE-2026-93782Kernel, userspace & hypervisorcurated

Impact

vhost-scsi translates guest response descriptors into host userspace iovecs at submission time, but target-core completes asynchronously. VHOST_SET_MEM_TABLE can swap the memory table while a command still holds iovecs translated through the old one, so the completion writes the SCSI response into an unrelated userspace object in the VMM process. The CVSS vector records a scope change - this crosses the VM boundary into the hypervisor process, which is exactly the boundary a GPU cloud sells. On nodes that pass GPUs into KVM guests with vhost-scsi storage, a guest that can drive the ioctl sequence gets a write into host VMM memory.

Who can reach it

Local - whoever controls the vhost-scsi device file and the ioctl sequence, i.e. the VMM process serving a guest, or a guest able to influence it. High attack complexity: the race between an in-flight command and the memory-table update has to be won. Only hosts using vhost-scsi are affected.

What to do

Install a kernel with the vhost-scsi backend-flush fix and reboot the hypervisor hosts; live migration of guests off the node first keeps the cost to a rolling drain. Hosts that do not use vhost-scsi storage for guests can defer.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.