CVE-2026-43321

What it actually does

This vulnerability is a local privilege escalation flaw in the Linux kernel eBPF verifier. The issue relates to how the verifier computes live registers for indirect jump instructions, specifically `gotox rX`. If the register used as the indirect jump target is not correctly marked as live, verifier analysis may make unsafe assumptions about register state or control flow. A local user who can load eBPF programs may be able to craft a malicious BPF program that passes verification despite unsafe behavior, potentially leading to kernel memory corruption, arbitrary kernel read/write primitives, or execution with elevated privileges. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Successful exploitation could allow a low-privileged local user or compromised application account on a Linux system to gain root-level control of the host. This can lead to theft of sensitive data, tampering with workloads, installation of persistence, disabling of security controls, or disruption of critical services. The issue is not currently listed in CISA KEV, has no known public exploit maturity, and has a low EPSS score, so broad active exploitation is not indicated; however, kernel privilege escalation flaws are high-value post-compromise tools and should be prioritized on multi-user systems, container hosts, CI/CD runners, developer workstations, and any environment where untrusted users or workloads can execute code.

How an attack unfolds

An attacker first needs local code execution with a low-privileged account or within a workload that can reach the Linux kernel's BPF program loading path. The attacker then attempts to load a specially crafted eBPF program containing an indirect jump pattern such as `gotox rX` that exploits incorrect live-register marking in the verifier. If the vulnerable verifier accepts the program, the attacker can use the resulting unsafe BPF execution behavior to manipulate kernel memory or bypass expected verifier constraints. From there, the attacker may build a kernel read/write primitive, alter credential structures, escape sandbox boundaries where applicable, or otherwise elevate privileges to root. After privilege escalation, the attacker can access protected files, modify system configuration, load additional payloads, create persistence, or disable logging and security agents.

How to fix it

Apply a Linux kernel update from the relevant distribution or vendor that includes the upstream fix for the BPF live-register handling issue described as `bpf: Properly mark live registers for indirect jumps`. No specific fixed package versions were provided in the input, so remediation should be validated against vendor advisories and kernel changelogs for the affected distribution. After installing the patched kernel, reboot the host to ensure the fixed kernel is running. As a mitigation where immediate patching is not possible, restrict unprivileged eBPF use by setting `kernel.unprivileged_bpf_disabled=1` or the vendor-recommended equivalent, limit access to capabilities such as `CAP_BPF`, `CAP_SYS_ADMIN`, and `CAP_PERFMON`, reduce local shell access on shared systems, and harden container runtimes so untrusted workloads cannot load BPF programs. These mitigations reduce exploitability but should not be treated as substitutes for applying the fixed kernel.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not just the installed kernel package, contains the vendor fix. Use distribution package tools and `uname -r` after reboot to ensure the active kernel matches a patched release. Review vendor security advisories or changelogs for the BPF fix text `bpf: Properly mark live registers for indirect jumps`. Validate mitigation by checking `sysctl kernel.unprivileged_bpf_disabled`; a value of `1` or a vendor-supported permanently disabled value indicates unprivileged BPF loading is restricted. Also confirm that untrusted users, containers, and services do not retain unnecessary BPF-related capabilities. Where feasible, attempt a controlled BPF load test from an unprivileged account to verify that unprivileged program loading is blocked on systems relying on mitigation.

Typical attack path

1. Obtain local execution on a Linux host through a compromised user account, application, containerized workload, CI job, or other low-privileged execution context.
2. Determine whether the kernel is a vulnerable build and whether the attacker can invoke the BPF syscall or otherwise load eBPF programs.
3. Craft or deploy an eBPF program using an indirect jump sequence that triggers incorrect live-register handling in the kernel BPF verifier.
4. Submit the malicious BPF program for verification and loading using the `bpf()` syscall or tooling that ultimately calls it.
5. Abuse the verifier inconsistency to gain unsafe BPF behavior, such as out-of-bounds access, type confusion, or a kernel memory read/write primitive.
6. Use the kernel primitive to modify process credentials, disable protections, escape confinement, or otherwise gain root-equivalent privileges.
7. Perform follow-on actions such as credential theft, persistence, lateral movement preparation, or service disruption.

How to detect it

There are no public, vulnerability-specific indicators of compromise provided for this issue, and exploitation may leave few durable artifacts because eBPF activity occurs inside the kernel. Detection should focus on behavioral evidence. Review audit logs for use of the `bpf()` syscall, especially `BPF_PROG_LOAD`, by non-root users, unexpected service accounts, containers, build jobs, or processes that do not normally load eBPF programs. Correlate BPF program-load events with subsequent privilege changes, new root-owned files, suspicious `setuid` binaries, kernel warnings, crashes, abnormal process credentials, or security tooling failures. Useful log sources include Linux auditd, eBPF observability platform logs, endpoint detection telemetry, container runtime logs, kernel logs, sudo/authentication logs, and process execution telemetry. On systems with auditd, consider rules that capture BPF syscall usage and capability changes. Because benign observability, networking, and security tools commonly use eBPF, treat BPF activity as suspicious when it is new, user-initiated, associated with untrusted accounts, or followed by root-level execution without an expected administrative path.

What your security team should do

• Inventory Linux systems and prioritize patching for internet-facing hosts, multi-user servers, container hosts, CI/CD runners, Kubernetes nodes, bastion hosts, and systems where untrusted users or workloads can execute code.
• Apply vendor kernel updates that include the BPF live-register fix, then reboot systems so the patched kernel is active.
• Temporarily disable or restrict unprivileged eBPF loading on systems that cannot be patched immediately.
• Audit users, containers, and services with `CAP_BPF`, `CAP_SYS_ADMIN`, or `CAP_PERFMON`, and remove these capabilities unless explicitly required.
• Enable or tune audit logging for BPF program loads and suspicious local privilege escalation activity, especially on high-risk shared Linux infrastructure.
• Hunt for unusual BPF program loading by non-administrative users, unexpected compiler/toolchain use on production systems, and privilege transitions shortly after BPF activity.
• Monitor vendor advisories because exploit maturity may change even though the current EPSS score is low and the vulnerability is not listed in CISA KEV.