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

Published Sep 25, 2026
·
Updated

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 bpfloop() verifier marks R1 (and R4) as precise. R1 tracks loop iterations number and because of the 'callbackdepth < R1' mechanics in checkhelpercall() must be marked precise. However, precision propagation for R1 was broken, when bpfloop() call was verified on a second iteration.

Consider the following verification trace: - main: bpfloop(nrloops, callback ...) - callback: BPFEXIT - main: bpfloop(nrloops, callback ...) - ...

While the first visit of the call to bpfloop() propagated R1 precision as expected, the second call to markchainprecision() in the checkhelpercall() set R1, but it was immediately reset when backtrackinsn() processed preceding BPFEXIT in the loop deleted in this patch.

Because of that, the second visit of the call to bpfloop() 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'.

Affected Software

1 affected component
Linux Linux kernel

Event History

Sep 25, 2026
CVE Published
via MITRE·10:24 AM
Data Sourced
via MITRE·10:24 AM
Description

Frequently Asked Questions

1

What conditions are required for exploitation?

An attacker would need to load a crafted eBPF program that uses bpf_loop() and reaches repeated verifier processing of the helper call. The flaw can cause the verifier to accept an unsafe program by failing to preserve precision tracking for R1 on a later visit.

2

Who is realistically exposed?

Systems that allow an attacker or untrusted workload to submit eBPF programs for kernel verification are the relevant exposure boundary. The provided information does not identify affected kernel versions or specific configurations.

3

How can I tell whether my kernel includes the fix?

Check whether the kernel contains either referenced stable commit: f83890dfed9efc5e19df1dbc1ad707a142936923 or e3e4f66cc4b72333d0886ae2673c360248987889. The supplied data does not provide release-version mappings for those commits.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203