CVE-2026-97994: vhost/vdpa: reject VRING_NUM larger than device max
In the Linux kernel, the following vulnerability has been resolved:
vhost/vdpa: reject VRINGNUM larger than device max
vhostvringsetnum() accepts any non-zero power-of-two queue size that fits in 16 bits. vhost-vdpa then passes that value to setvqnum() without comparing it with getvqnummax().
A process with access to /dev/vhost-vdpa- can therefore configure a queue larger than the device advertises. With vdpasim, the worker can walk descriptors beyond the mapped descriptor ring. KASAN reports a 16-byte out-of-bounds read, corresponding to one vringdesc, in the vringh IOTLB path:
BUG: KASAN: out-of-bounds in copyfromiter Read of size 16 copyfromiotlb copydesciotlb vringhgetdesciotlb vdpasimnetwork
Cache getvqnummax() immediately after reset. Some backends derive it from writable queue-size state, so querying it after SETNUM may return the current size instead of the device capability. Invalidate the cached value before reset so a failed reset leaves SETNUM disabled.
For VHOSTSETVRINGNUM, copy the complete vring state once and use the same index and size for validation, vq->num, and setvqnum(). This ensures that validation and use operate on the same copied values.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In vhost-vdpa, reject VRING_NUM values larger than the device maximum by comparing the requested queue size with get_vq_num_max(); copy the complete vring state once and use the same copied index and size for validation, vq->num, and set_vq_num(). Cache get_vq_num_max() immediately after reset and invalidate the cached value before reset so a failed reset leaves SET_NUM consistent.
Event History
Frequently Asked Questions
Who can trigger the vulnerable queue configuration?
A process with access to a /dev/vhost-vdpa-* device can configure a queue size larger than the device advertises. This is therefore primarily relevant to systems that expose vhost-vdpa device nodes to untrusted or less-trusted processes.
What conditions are needed for the out-of-bounds access described?
The process must set a non-zero power-of-two VRING_NUM value that fits in 16 bits but exceeds the device maximum. The described out-of-bounds descriptor access occurs with the vdpa_sim backend when its worker processes the oversized ring.
How does the fix prevent this condition?
The fix obtains and caches the device maximum queue size immediately after reset, then rejects VHOST_SET_VRING_NUM values larger than that maximum. It also invalidates the cached value before reset so SET_NUM remains disabled if reset fails.