GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel vhost-vdpa: queue size is not checked against the device maximum, giving an out-of-bounds descriptor read

UnscoredCVE-2026-97994Kernel, userspace & hypervisorcurated

Impact

vhost_vring_set_num() accepts any non-zero power-of-two 16-bit queue size, and vhost-vdpa passed it straight to set_vq_num() without comparing it to get_vq_num_max(). A process that can open /dev/vhost-vdpa-* can therefore configure a virtqueue larger than the device advertises, and the worker then walks descriptors past the end of the mapped descriptor ring - KASAN reports a 16-byte out-of-bounds read of one vring_desc in the vringh IOTLB path. On a hypervisor host that hands vDPA devices to guests, this is host-side memory disclosure or a host crash driven from whoever holds the vhost-vdpa character device, which on a GPU virtualization node is the VM management stack rather than an ordinary tenant. Only relevant where vDPA is actually in use; hosts with no vhost-vdpa devices are unaffected.

Who can reach it

Local user or service with access to /dev/vhost-vdpa-* on the host (typically the VM/management layer, not a tenant). No remote path and no credentials beyond that device permission.

What to do

Update to a stable kernel containing the fix (the upstream change caches get_vq_num_max() after reset and validates the copied vring state before use) and reboot the node. On a GPU host that means draining tenant workloads first, so this lands in a normal kernel maintenance window. Interim mitigation: restrict permissions on /dev/vhost-vdpa-* to the VM management service only, or avoid vDPA devices on hosts that do not need them.

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.