Linux: Incorrect Calculation
CVE-2026-43009 is a high-severity incorrect calculation vulnerability in Linux, with a CVSS 3.1 base score of 7.8 out of 10. It can be exploited with local access to the system by an attacker with a low-privileged account, without any action from a user. The record lists versions 06999c8a2c52b13977771ab093b8e179821b532d, 1aac6b271e0a80b91c2f6a8f75ab0c0b1fc8ffe8, 7c72e5f3741d1c5cc53439137162f0e09254e6e9 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.16% chance of exploitation within 30 days, which is low compared with other CVEs.
High severity with no evidence of exploitation so far.
What to do
- Update Linux to 06999c8a2c52b13977771ab093b8e179821b532d or 1aac6b271e0a80b91c2f6a8f75ab0c0b1fc8ffe8 or 7c72e5f3741d1c5cc53439137162f0e09254e6e9 or ea150ffa9fc9f78c5cf22e1f7b06b6d016b1017c, whichever matches your release line, or a later version.
- Update Linux Kernel to 6.19.12 or a later version.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Linux | Linux | 5ca419f2864a2c60940dcf4bbaeb69546200e36f up to, but not including, 06999c8a2c52b13977771ab093b8e179821b532d; 5ca419f2864a2c60940dcf4bbaeb69546200e36f up to, but not including, 1aac6b271e0a80b91c2f6a8f75ab0c0b1fc8ffe8; 5ca419f2864a2c60940dcf4bbaeb69546200e36f up to, but not including, 7c72e5f3741d1c5cc53439137162f0e09254e6e9; 5ca419f2864a2c60940dcf4bbaeb69546200e36f up to, but not including, ea150ffa9fc9f78c5cf22e1f7b06b6d016b1017c; 5ca419f2864a2c60940dcf4bbaeb69546200e36f up to, but not including, 7ffbe45b1d227e24659998a91cfd4c27af457e71; 5ca419f2864a2c60940dcf4bbaeb69546200e36f up to, but not including, 179ee84a89114b854ac2dd1d293633a7f6c8dac1; 5.12 | 06999c8a2c52b13977771ab093b8e179821b532d, 1aac6b271e0a80b91c2f6a8f75ab0c0b1fc8ffe8, 7c72e5f3741d1c5cc53439137162f0e09254e6e9, ea150ffa9fc9f78c5cf22e1f7b06b6d016b1017c, 7ffbe45b1d227e24659998a91cfd4c27af457e71, 179ee84a89114b854ac2dd1d293633a7f6c8dac1 |
| Linux | Linux Kernel | 5.12 up to, but not including, 6.19.12; 7.0 | 6.19.12 |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- LocalThe attacker needs local access or must trick a user into running something.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Privileges required
- LowA basic user account is enough.
- User interaction
- NoneNo action by a victim is required.
- Scope
- UnchangedImpact stays within the vulnerable component.
- Confidentiality
- HighAll data handled by the component can be read.
- Integrity
- HighData or code can be modified at will.
- Availability
- HighThe component can be taken down completely.
Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Scored by CNA.
Official 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
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Incorrect Calculation
The product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.
How developers prevent this class of flaw
- Understand your programming language's underlying representation and how it interacts with numeric calculation. Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, not-a-number calculations, and how your language handles numbers that are too large or too small for its underlying representation.
- Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range.
- Use the appropriate type for the desired action. For example, in C/C++, only use unsigned types for values that could never be negative, such as height, width, or other numbers related to quantity.
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: total).
- Record last changed materially (score, affected products, status or references).
References
Patches and release notes
Other references
Recent Incorrect Calculation vulnerabilities
- 7.8 High severity
- 7.8 High severity
- 9.8 Critical severity
- 7.5 High severity
- 7.1 High severity
- 8.8 High severity
Spotted an error? Tell us.