CVE-2026-43009: bpf: Fix incorrect pruning due to atomic fetch precision tracking
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix incorrect pruning due to atomic fetch precision tracking
When backtrackinsn encounters a BPFSTX instruction with BPFATOMIC and BPFFETCH, the src register (or r0 for BPFCMPXCHG) 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 backtrackinsn 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 BPFLDX handling in backtrackinsn to also cover atomic fetch operations via isatomicfetchinsn() 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 BPFLDX. 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 = atomic64fetchadd((u64 )(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5: (0f) r3 += r2 markprecise: frame0: lastidx 5 firstidx 0 subseqidx -1 markprecise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 markprecise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64fetchadd((u64 )(r10 -8), r2) markprecise: 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 = atomic64fetchadd((u64 )(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5: (0f) r3 += r2 markprecise: frame0: lastidx 5 firstidx 0 subseqidx -1 markprecise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 markprecise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64fetchadd((u64 )(r10 -8), r2) markprecise: frame0: regs= stack=-8 before 2: (b7) r2 = 0 markprecise: frame0: regs= stack=-8 before 1: (7b) (u64 )(r10 -8) = r1 markprecise: frame0: regs=r1 stack= before 0: (b7) r1 = 8 6: R2=8 R3=fp8 6: (b7) r0 = 0 ; R0=0 7: (95) exit
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Extend BPF_LDX handling in backtrack_insn to correctly account for non-stack memory and atomic fetch variants (covering all fetch variants and atomic fetch operations via is_atomic_fetch_insn() helper) so verifier path pruning does not incorrectly consider equivalent branches when atomic fetch precision tracking differs in terms of stack state.
Event History
Frequently Asked Questions
What is the severity of CVE-2026-43009?
CVE-2026-43009 has been classified with a medium severity due to its potential impact on atomic fetch precision tracking.
How do I fix CVE-2026-43009?
To fix CVE-2026-43009, update your Linux kernel to the latest stable version that addresses this vulnerability.
What types of systems are affected by CVE-2026-43009?
CVE-2026-43009 affects the Linux kernel across various distributions and versions.
What is the impact of CVE-2026-43009?
CVE-2026-43009 may lead to incorrect data handling in applications utilizing BPF due to flawed atomic fetch precision tracking.
When was CVE-2026-43009 reported?
CVE-2026-43009 was officially documented and addressed in patches released in 2026.