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 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
Security readout for executives and security teams
Plain-English summary
A Linux kernel BPF verifier flaw can incorrectly treat different program states as equivalent and skip necessary analysis. On affected systems, this may allow unsafe BPF behavior to pass verification. The supplied CVSS assessment rates potential confidentiality, integrity, and availability impact as high, but exploitation still requires local, low-privileged access.
Executive priority
Treat as a high-priority kernel update, especially for shared, multi-user, or workload-hosting systems. Prioritize assets where low-privileged actors can access BPF functionality. There is no supplied evidence of active exploitation, so urgency should reflect exposure rather than an assumed ongoing campaign.
Technical view
Atomic BPF fetch operations make the source register, or r0 for CMPXCHG, receive the previous memory value. Precision backtracking failed to propagate that dependency to the stack slot. Consequently, verifier path pruning could merge materially different stack states. The cited Linux stable commits extend load-style precision handling to atomic fetch variants.
Likely exposure
Exposure applies to affected Linux kernels capable of processing the relevant BPF atomic-fetch instructions. Risk is greatest where low-privileged local users or workloads can reach BPF functionality. The bundle's flattened version data is ambiguous, so exact affected and fixed builds must be confirmed through distribution guidance and cited fixes.
Exploitation context
No active exploitation is established: the bundle marks this CVE as absent from KEV and provides no evidence of public exploitation. CVSS describes a local, low-complexity attack requiring low privileges and no user interaction. Public exploit availability is not established by the supplied sources.
Researcher notes
The defect concerns verifier soundness during precision backtracking, specifically atomic operations combining BPF_ATOMIC and BPF_FETCH. Stack-backed fetches require precision propagation to the originating slot; non-stack walks stop at the instruction. The fix reportedly covers fetch variants, including CMPXCHG through r0. The supplied material does not demonstrate a complete privilege-escalation chain.
Mitigation direction
Apply a vendor kernel update containing the applicable cited stable fix.
Consult distribution guidance because the supplied affected-version boundaries are ambiguous.
Reboot affected systems into the updated kernel after following change-control procedures.
Until patched, reduce low-privileged access to exposed hosts where operationally feasible.
Validation and detection
Inventory running kernel versions across hosts, containers' hosts, and appliances.
Compare each build with distribution advisories and the cited stable fixes.
Confirm the applicable fix appears in package changelogs, source history, or vendor documentation.
After rebooting, verify every node is running the intended updated kernel.
Run approved BPF and kernel regression tests for custom kernel builds.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-43009 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
3Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.