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'.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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'.
    (CVE-2026-98084)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
376443	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel vulnerabilities (USN-8959-1)	Nessus	Ubuntu Local Security Checks	Local	high
373466	Amazon Linux 2023 : bpftool6.12, kernel6.12, kernel6.12-devel (ALAS2023-2026-3335)	Nessus	Amazon Linux Local Security Checks	Local	medium
371850	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-3251)	Nessus	Amazon Linux Local Security Checks	Local	critical
350566	Linux Distros Unpatched Vulnerability : CVE-2026-98084	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2026-98084

high

Tenable Plugins

high

medium

critical

medium