CVE-2026-98084 Affecting kernel-livepatch-6.18.56-125.164 package, versions <1:1.0-0.amzn2023
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-AMZN2023-KERNELLIVEPATCH61856125164-21701467
- published25 Oct 2026
- disclosed25 Sept 2026
Introduced: 25 Sep 2026
CVE-2026-98084 (opens in a new tab)How to fix?
Upgrade Amazon-Linux:2023 kernel-livepatch-6.18.56-125.164 to version 1:1.0-0.amzn2023 or higher.
This issue was patched in ALAS2023-2026-3251.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-livepatch-6.18.56-125.164 package and not the kernel-livepatch-6.18.56-125.164 package as distributed by Amazon-Linux.
See How to fix? for Amazon-Linux:2023 relevant fixed versions and status.
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
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-98084
- https://git.kernel.org/stable/c/e3e4f66cc4b72333d0886ae2673c360248987889
- https://git.kernel.org/stable/c/f83890dfed9efc5e19df1dbc1ad707a142936923
- https://git.kernel.org/stable/c/3a39bc9707fbd1bef4df7318a9d02222741dda5b
- https://git.kernel.org/stable/c/1ac58dab0a83d2c64e3b807a3a0b399f17a74110
- https://git.kernel.org/stable/c/cdc93c6370f792d0649df2a145ac0cdcd430e411