GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel vhost-scsi (VHOST_SET_FEATURES after endpoint setup): vhost_scsi_setup_vq_cmds() sizes each command's

CVE-2026-74702Kernel, userspace & hypervisorcurated

Impact

vhost_scsi_setup_vq_cmds() sizes each command's protection scatterlist from the VIRTIO_SCSI_F_T10_PI bit acknowledged at VHOST_SCSI_SET_ENDPOINT time, but vhost_scsi_set_features() still accepts a feature change afterwards without rebuilding the pools. Turning T10-PI on after the endpoint is live leaves prot_sgl NULL while the I/O path follows the new bit, and a large protection payload trips BUG_ON in sg_pool_index(), taking down the vhost worker and the host path behind it. On a GPU node running virtualized tenants with vhost-scsi backing their disks, that is a host-side kernel BUG triggered by the VMM process - a node-level availability problem on a machine whose accelerators are pinned to running guests. The record shows a NULL-ish dereference and BUG_ON, not a demonstrated escape.

Who can reach it

Local on the host, from whatever holds the vhost-scsi control fd - normally the QEMU/VMM process, not the guest. Requires the ability to issue VHOST_SET_FEATURES on an already-configured endpoint. A guest cannot reach it directly; a compromised or buggy VMM can.

What to do

Apply the stable fix, which rejects changes to any feature other than VHOST_F_LOG_ALL while the endpoint is active; userspace must clear the endpoint before renegotiating and set it up again. Deploying it is a kernel update and reboot per hypervisor node, so migrate or drain guests first. Hosts that do not use vhost-scsi are unaffected and can wait for the normal kernel roll.

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.