CVE-2026-43009

What it actually does

This is a Linux kernel eBPF verifier flaw in precision tracking for atomic fetch operations. When a BPF atomic fetch instruction both reads from memory and writes the old value back into a register, the verifier may fail to propagate precision information from the destination register back to the relevant stack slot. Because verifier path-pruning can then incorrectly treat two different program states as equivalent, a crafted eBPF program may be accepted when it should be rejected. In the worst case, this can undermine eBPF safety checks and enable a local attacker to achieve kernel memory access or kernel-level code execution, resulting in local privilege escalation with confidentiality, integrity, and availability impact.

Why it matters to the business

Successful exploitation could allow a local user or compromised low-privilege process to gain root or kernel-level control of a Linux system. That can lead to data theft, tampering with security controls, persistence, service disruption, and full host compromise. The current public exploitation signal is low: EPSS is 0.00134 and stable over 30 days, it is not listed in CISA KEV, and no public exploit maturity is indicated. However, because the affected component is the Linux kernel and eBPF is widely deployed across modern Linux estates, exposed systems should still be patched during normal kernel maintenance windows, with higher priority for multi-user systems, container hosts, CI/CD runners, and environments where unprivileged eBPF is enabled.

How an attack unfolds

An attacker first needs local code execution on an affected Linux host, typically through a shell, compromised application account, container escape foothold attempt, or another low-privilege user context. The attacker then attempts to load a specially crafted eBPF program that uses atomic fetch operations in a way that triggers the verifier precision-tracking bug. If the system permits the attacker to load eBPF programs, either because unprivileged eBPF is enabled or the attacker has relevant capabilities such as CAP_BPF, CAP_SYS_ADMIN, or equivalent delegation, the flawed verifier may incorrectly prune verification paths and accept an unsafe program. Once accepted, the eBPF program may be used to manipulate kernel memory or influence kernel execution, allowing privilege escalation to root or kernel-level control. Exploitation is local and depends heavily on kernel configuration, eBPF access controls, hardening settings, and whether the attacker can reach BPF program-loading interfaces.

How to fix it

Upgrade to a Linux kernel version that contains the upstream fix for the eBPF verifier atomic fetch precision-tracking issue. Because no exact fixed package versions were provided, use the fixed kernel builds supplied by the relevant Linux distribution or vendor advisory for this CVE and reboot into the patched kernel. Where immediate patching is not possible, reduce exposure by disabling unprivileged eBPF loading, restricting BPF-related capabilities, limiting access to privileged containers, and ensuring only trusted administrators can load BPF programs. Common hardening controls include setting kernel.unprivileged_bpf_disabled=1 where supported, avoiding broad CAP_SYS_ADMIN or CAP_BPF grants, using container profiles that block the bpf() syscall for untrusted workloads, and enforcing seccomp/AppArmor/SELinux policies that prevent BPF program loading by non-administrative processes.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is updated to a vendor build that includes the fix. Validate with uname -a, package manager kernel version checks, and vendor advisory metadata. Reboot if the fixed kernel is installed but not running. Verify eBPF exposure by checking whether unprivileged BPF is disabled, whether untrusted users or containers have CAP_BPF or CAP_SYS_ADMIN, and whether seccomp or LSM policy blocks the bpf() syscall where appropriate. If available, use vendor vulnerability scanners or kernel livepatch status tools to confirm the CVE is remediated. For mitigation validation, attempt BPF program loading from an unprivileged test account in a controlled environment and confirm it is denied unless explicitly required.

Typical attack path

1. Obtain local execution as a low-privilege user, service account, or constrained container process on an affected Linux host.
2. Check whether eBPF program loading is available through unprivileged BPF or granted capabilities such as CAP_BPF or CAP_SYS_ADMIN.
3. Prepare a malicious eBPF program that uses atomic fetch instructions to trigger incorrect verifier precision tracking and path pruning.
4. Invoke the bpf() system call to create required maps and load the crafted BPF program.
5. Attach or execute the accepted BPF program through an available hook or trigger path.
6. Use the verifier bypass effect to gain unsafe kernel memory access or kernel execution primitives.
7. Escalate privileges, disable defenses, access sensitive data, or establish persistence on the host.

How to detect it

There are no definitive, universally reliable indicators that prove exploitation of this kernel verifier flaw after the fact. Detection should focus on evidence of suspicious eBPF program loading and follow-on local privilege escalation. Review auditd, EDR, kernel logs, systemd journal, command history, process execution telemetry, and container runtime logs for bpf() system calls, BPF_PROG_LOAD activity, unexpected use of bpftool, BPF activity by web service or application users, and BPF loading from containers or CI jobs. Correlate these events with privilege changes, new root-owned files, unexpected setuid binaries, kernel warnings, Oops or BUG messages, service crashes, module/security-control tampering, or unusual outbound connections. On systems with audit enabled, search for syscall=bpf, BPF_PROG_LOAD, BPF_MAP_CREATE, and executions of bpftool by non-administrative accounts. On container platforms, review workloads granted CAP_BPF, CAP_SYS_ADMIN, privileged=true, or policies that allow the bpf syscall. Because benign observability and networking tools may legitimately use eBPF, prioritize anomalous sources, new binaries, unusual parent processes, and activity from accounts or containers that normally do not load BPF programs.

• syscall=bpf
• BPF_PROG_LOAD
• BPF_MAP_CREATE
• comm="bpftool"
• exe="/usr/sbin/bpftool"
• exe="/sbin/bpftool"
• /usr/sbin/bpftool
• /sys/fs/bpf
• kernel.unprivileged_bpf_disabled=0
• CAP_BPF
• CAP_SYS_ADMIN
• privileged=true
• atomic64_fetch_add
• atomic_fetch_add
• BPF_ATOMIC
• BPF_FETCH
• kernel: BUG:
• kernel: Oops:
• general protection fault

What your security team should do

• Prioritize patching Linux kernels on multi-tenant servers, container hosts, Kubernetes nodes, CI/CD runners, bastion hosts, and systems where untrusted users can execute code.
• Reboot systems into the fixed kernel after installing updates; do not rely solely on package installation status.
• Disable unprivileged eBPF loading unless there is a documented operational requirement.
• Review and remove unnecessary CAP_BPF, CAP_SYS_ADMIN, privileged container, and hostPID/hostNetwork-style grants from workloads and users.
• Add audit or EDR monitoring for bpf() system calls, BPF_PROG_LOAD events, unexpected bpftool usage, and BPF activity by non-administrative processes.
• Hunt for suspicious local privilege escalation behavior following BPF program loads, including new root shells, credential changes, kernel crashes, and unexpected security control tampering.
• Track vendor advisories for exact fixed kernel package versions and livepatch availability across all Linux distributions in use.
• Treat exploitation likelihood as currently low due to stable low EPSS, no KEV listing, and no known public exploit maturity, but maintain urgency because successful exploitation can produce full host compromise.