CVE-2026-98084: Linux kernel · bpf: backtracking shouldn't clear outer frame R1-R5 for callbacks
Affects Linux kernelSource CVE Database V5
Not known to be exploited · fixed in f83890dfed9efc5e19df1dbc1ad707a142936923 : update Linux kernel when convenient.
Data as of 26 Oct 2026, 13:47 UTC
Rated by Threat Radar · CVSS not yet scored by NVD
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 5% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in f83890dfed9efc5e19df1dbc1ad707a142936923, e3e4f66cc4b72333d0886ae2673c360248987889, cdc93c6370f792d0649df2a145ac0cdcd430e411 +3
Exploitation evidence
Disclosed: evidence found.
CVE published 25 Sep 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in– |
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'.
References
- git.kernel.org/stable/c/1ac58dab0a83d2c64e3b807a3a0b399f17a74110 (opens in a new tab)
- git.kernel.org/stable/c/cdc93c6370f792d0649df2a145ac0cdcd430e411 (opens in a new tab)
- git.kernel.org/stable/c/3a39bc9707fbd1bef4df7318a9d02222741dda5b (opens in a new tab)
- git.kernel.org/stable/c/f83890dfed9efc5e19df1dbc1ad707a142936923 (opens in a new tab)
- git.kernel.org/stable/c/e3e4f66cc4b72333d0886ae2673c360248987889 (opens in a new tab)