CVE-2026-43030

What it actually does

This is a local privilege escalation flaw in the Linux kernel eBPF verifier. A verifier state-pruning bug in regsafe() can incorrectly treat a packet-pointer register state as safe when the previous state was beyond the packet end and the current state has a valid range. That can cause the verifier to skip exploration of a state it should analyze, potentially allowing a crafted BPF program to pass verification with unsafe packet-pointer assumptions. If exploitable on a given kernel configuration, this may allow a local user with permission to load BPF programs to achieve kernel memory corruption or otherwise execute code with kernel privileges, resulting in full compromise of confidentiality, integrity, and availability of the host.

Why it matters to the business

Successful exploitation could allow a low-privileged local user or compromised workload to take control of the underlying Linux host. This is especially significant for shared Linux servers, container platforms, CI runners, developer workstations, and multi-tenant environments where local code execution is expected or exposed. The current EPSS is very low and there is no known KEV listing or public exploit maturity indicated, but the CVSS impact is high because a working exploit could provide full host-level compromise.

How an attack unfolds

An attacker first obtains local code execution on a vulnerable Linux system, such as through a compromised user account, application shell, container escape precondition, CI job, or malicious local process. The attacker then attempts to load a specially crafted BPF program that manipulates packet-pointer verifier state so the kernel verifier incorrectly considers an unsafe state equivalent to a previously explored safe state. If the verifier accepts the program, the attacker triggers the unsafe execution path to corrupt or read kernel memory, influence control flow, or gain elevated capabilities. With successful exploitation, the attacker can escalate from a low-privileged local context to root or kernel-level control, disable security tooling, access sensitive data, or pivot further inside the environment.

How to fix it

Apply the Linux kernel update from the relevant distribution or vendor that includes the upstream fix for the BPF regsafe() packet-pointer verifier bug. No exact fixed package versions were provided, so remediation should be based on vendor advisories for the affected kernel stream. Where immediate patching is not possible, reduce exposure by disabling unprivileged BPF using sysctl settings such as kernel.unprivileged_bpf_disabled=1 or, where supported and operationally acceptable, =2 for a stronger irreversible setting until reboot. Restrict BPF-related capabilities to trusted administrative processes only, especially CAP_BPF, CAP_PERFMON, CAP_NET_ADMIN, and CAP_SYS_ADMIN. Limit local shell access, harden container runtimes, avoid privileged containers, and use seccomp/AppArmor/SELinux policies to restrict the bpf() syscall where workloads do not require it.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build containing the fix, not merely that the package is installed. Validate with uname -a, package manager metadata, and the vendor security advisory for the deployed kernel branch. Check BPF exposure with sysctl kernel.unprivileged_bpf_disabled and confirm untrusted users cannot invoke the bpf() syscall. Review container and workload profiles to ensure untrusted workloads do not have excessive capabilities such as CAP_SYS_ADMIN, CAP_BPF, CAP_NET_ADMIN, or privileged mode. If compensating controls are used, test that non-administrative users cannot load BPF programs using bpftool or a simple bpf() syscall test program.

Typical attack path

1. Gain local code execution on a Linux host through a user account, compromised service, container, CI job, or other foothold.
2. Check whether BPF program loading is permitted, including unprivileged BPF status and availability of CAP_BPF, CAP_PERFMON, CAP_NET_ADMIN, or CAP_SYS_ADMIN.
3. Compile or stage a crafted eBPF program designed to exercise the packet-pointer verifier state-pruning bug.
4. Use the bpf() syscall or a loader such as bpftool, libbpf-based tooling, or custom code to load the malicious program.
5. Attach or trigger the BPF program through a relevant hook path, such as networking-related BPF execution context.
6. Exploit the unsafe verifier-approved state to corrupt or disclose kernel memory.
7. Escalate privileges to root or kernel-level control.
8. Persist, disable defenses, collect sensitive data, or pivot to additional systems.

How to detect it

There are no public exploit indicators or known KEV exploitation signals provided for this vulnerability. To assess possible prior exploitation, review Linux audit logs, EDR telemetry, shell history, process execution logs, and kernel logs for unexpected BPF program loading or use of the bpf() syscall by non-administrative users, application accounts, containers, or CI jobs. Useful sources include auditd records for the bpf syscall, execve logs for bpftool or custom BPF loaders, systemd journal entries, kernel oops/panic logs, EDR process ancestry, and container runtime events showing privileged containers or added Linux capabilities. Investigate sequences where BPF activity is followed by privilege escalation, new root-owned files, setuid binary creation, credential access, security control changes, kernel crashes, or anomalous network activity. Because successful exploitation may not leave a unique artifact, detection should focus on abnormal BPF usage patterns and post-exploitation behavior.

• syscall=bpf
• SYSCALL=bpf
• comm="bpftool"
• exe="/usr/sbin/bpftool"
• exe="/sbin/bpftool"
• kernel.unprivileged_bpf_disabled = 0
• unprivileged_bpf_disabled=0
• CAP_BPF
• CAP_SYS_ADMIN
• CAP_NET_ADMIN
• privileged=true
• --privileged
• setcap cap_bpf
• setcap cap_sys_admin
• /sys/fs/bpf
• /proc/sys/kernel/unprivileged_bpf_disabled

What your security team should do

• Prioritize patching Linux systems that allow local users, containers, CI jobs, build agents, research workloads, or other untrusted code execution.
• Inventory kernel versions across servers, endpoints, appliances, and container hosts, and map them to vendor advisories containing the BPF verifier fix.
• Disable unprivileged BPF on systems where it is not explicitly required.
• Restrict BPF-related capabilities and remove privileged container configurations wherever possible.
• Add monitoring for unexpected BPF program loading, especially by non-administrative users, application service accounts, containerized processes, or build jobs.
• Review recent local privilege escalation alerts, suspicious root shells, kernel crashes, and unexplained security-tool tampering on Linux hosts.
• Treat suspicious BPF activity followed by privilege escalation as a potential host compromise requiring forensic investigation.