CVE-2026-43009 in Linux
Summary
by MITRE • 05/01/2026
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
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/07/2026
The vulnerability described affects the Linux kernel's eBPF (extended Berkeley Packet Filter) subsystem, specifically within the verifier component responsible for ensuring program safety before execution. This issue stems from incorrect handling of atomic fetch operations during backtracking analysis, which is a critical phase in determining program correctness and precision tracking. The flaw manifests when the backtrack_insn function processes BPF_STX instructions that involve BPF_ATOMIC and BPF_FETCH operations, where the source register also serves as a destination receiving the original memory value. This dual role of registers in atomic fetch operations creates a precision tracking inconsistency that bypasses proper validation mechanisms.
The technical root cause lies in how the backtracking logic treats atomic fetch instructions compared to standard store operations. In regular stores, the source register is purely an input parameter, but in atomic fetch operations, it simultaneously acts as both input and output. The current implementation fails to recognize this distinction, leading to improper precision propagation to stack locations. This misclassification results in stack slots not being marked as precise when they should be, causing the verifier to incorrectly prune equivalent execution paths that actually differ in their stack state management. Such path pruning errors can lead to security vulnerabilities by allowing potentially unsafe code paths to be executed.
This vulnerability directly relates to CWE-691, which covers insufficient precision in atomic operations and improper handling of concurrent access patterns. The impact extends beyond simple verification failures to potentially enable bypass of kernel security controls through incorrect program analysis. The fix implemented modifies the backtrack_insn function to properly identify atomic fetch instructions using the is_atomic_fetch_insn() helper function. When such operations are detected, the system clears precision tracking from the destination register and appropriately propagates precision information to the corresponding stack slot. This approach maintains consistency with how regular BPF_LDX operations are handled while correctly addressing the unique characteristics of atomic fetch operations.
The operational implications of this vulnerability are significant for systems relying on eBPF for security monitoring, network filtering, and system observation. Incorrect path pruning could allow malicious programs to bypass kernel security checks or exploit race conditions in precision tracking. The fix ensures that all variants of atomic fetch operations are handled consistently, preventing false equivalencies between program states and maintaining the integrity of the verification process. This solution aligns with ATT&CK technique T1059.006 for execution through eBPF programs and addresses potential privilege escalation vectors in kernel security models. The patch demonstrates proper handling of complex register usage patterns in concurrent programming contexts, ensuring that precision tracking remains accurate even when dealing with atomic memory operations that have dual input/output semantics.
The corrected implementation properly distinguishes between regular store operations and atomic fetch operations during backtracking analysis. For non-stack memory access, the precision walk stops at the atomic instruction as it does for regular BPF_LDX, maintaining existing behavior while adding special handling for stack-based atomic fetches. This ensures that stack locations receive appropriate precision marking only when necessary, preventing both false positives and false negatives in verification decisions. The solution maintains backward compatibility while strengthening security boundaries through more accurate program analysis and path pruning decisions in the kernel's eBPF verifier subsystem.