CVE-2026-43009
Awaiting Analysis Awaiting Analysis - Queue
Incorrect BPF precision tracking in Linux kernel

Publication date: 2026-05-01

Last updated on: 2026-05-03

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix incorrect pruning due to atomic fetch precision tracking When backtrack_insn encounters a BPF_STX instruction with BPF_ATOMIC and BPF_FETCH, the src register (or r0 for BPF_CMPXCHG) also acts as a destination, thus receiving the old value from the memory location. The current backtracking logic does not account for this. It treats atomic fetch operations the same as regular stores where the src register is only an input. This leads the backtrack_insn to fail to propagate precision to the stack location, which is then not marked as precise! Later, the verifier's path pruning can incorrectly consider two states equivalent when they differ in terms of stack state. Meaning, two branches can be treated as equivalent and thus get pruned when they should not be seen as such. Fix it as follows: Extend the BPF_LDX handling in backtrack_insn to also cover atomic fetch operations via is_atomic_fetch_insn() helper. When the fetch dst register is being tracked for precision, clear it, and propagate precision over to the stack slot. For non-stack memory, the precision walk stops at the atomic instruction, same as regular BPF_LDX. This covers all fetch variants. Before: 0: (b7) r1 = 8 ; R1=8 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8 2: (b7) r2 = 0 ; R2=0 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5: (0f) r3 += r2 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) mark_precise: frame0: regs=r2 stack= before 2: (b7) r2 = 0 6: R2=8 R3=fp8 6: (b7) r0 = 0 ; R0=0 7: (95) exit After: 0: (b7) r1 = 8 ; R1=8 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8 2: (b7) r2 = 0 ; R2=0 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5: (0f) r3 += r2 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) mark_precise: frame0: regs= stack=-8 before 2: (b7) r2 = 0 mark_precise: frame0: regs= stack=-8 before 1: (7b) *(u64 *)(r10 -8) = r1 mark_precise: frame0: regs=r1 stack= before 0: (b7) r1 = 8 6: R2=8 R3=fp8 6: (b7) r0 = 0 ; R0=0 7: (95) exit
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-01
Last Modified
2026-05-03
Generated
2026-05-07
AI Q&A
2026-05-01
EPSS Evaluated
2026-05-05
NVD
CVE-2026-43009
EUVD
EUVD-2026-26608
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's BPF (Berkeley Packet Filter) subsystem, specifically in the backtracking logic of the verifier when handling atomic fetch instructions.

When the backtrack_insn function encounters a BPF_STX instruction with atomic fetch flags, it incorrectly treats the source register as only an input, ignoring that it also acts as a destination receiving the old memory value.

Because of this, the verifier fails to properly propagate precision information to the stack location, causing the verifier's path pruning to mistakenly consider two different states as equivalent and prune one branch incorrectly.

The fix extends the handling of atomic fetch instructions to correctly track precision and stack state, preventing incorrect pruning of verifier paths.


How can this vulnerability impact me? :

This vulnerability can cause the Linux kernel's BPF verifier to incorrectly prune execution paths that should be distinct, potentially leading to incorrect verification of BPF programs.

Such incorrect pruning might allow buggy or malicious BPF programs to pass verification, which could result in unexpected behavior or security issues within the kernel.

However, the exact impact depends on how BPF programs are used in your environment and whether this verification flaw can be exploited.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability has been resolved in the Linux kernel by fixing the incorrect pruning due to atomic fetch precision tracking in the BPF verifier.

To mitigate this vulnerability, you should update your Linux kernel to a version that includes this fix.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart