CVE-2026-53092

What it actually does

This is a Linux kernel eBPF verifier flaw involving incorrect register delta tracking when an eBPF instruction uses the same pointer register as both source and destination, such as rX += rX. Because the verifier updates the destination register in place and then reads the already-mutated source value, it can propagate an incorrect state to linked registers. The result is a verifier-versus-runtime mismatch: the verifier may believe a pointer or scalar value remains within safe bounds while the actual runtime value differs. In kernel verifier bugs, this class of mismatch can sometimes be used to bypass eBPF safety checks and may lead to out-of-bounds memory access, kernel memory corruption, information disclosure, denial of service, or local privilege escalation, depending on kernel configuration and exploitability. Exploitation generally requires the ability to load eBPF programs, which is typically restricted to privileged users or processes with capabilities such as CAP_BPF, CAP_SYS_ADMIN, or CAP_PERFMON, unless unprivileged eBPF is enabled.

Why it matters to the business

Successful exploitation could allow a local attacker or compromised workload with eBPF loading rights to destabilize the host or potentially escalate privileges to kernel-level control. The main operational risk is to Linux systems that allow unprivileged eBPF or that run services, agents, containers, or users with permissions to load BPF programs. This issue is not currently listed in CISA KEV, is not reported as used in ransomware campaigns, has no known public exploit maturity in the provided data, and has a low EPSS score, so broad internet-scale exploitation appears unlikely at this time. However, because kernel privilege escalation issues can turn limited local access into full host compromise, patching should still be prioritized on multi-tenant, containerized, developer, build, CI/CD, and shared Linux infrastructure.

How an attack unfolds

An attacker first needs local code execution on a Linux system and the ability to invoke the bpf() syscall to load an eBPF program. They then craft a BPF program that exercises the verifier corner case where the same linked pointer register is used as both the source and destination in an arithmetic operation. During verification, the kernel incorrectly calculates and propagates register deltas, causing the verifier's safety model to diverge from the values that will exist when the program actually runs. If the attacker can shape this mismatch into an unsafe memory access primitive, they may be able to read or corrupt kernel memory, crash the system, or build a privilege-escalation chain. Systems with unprivileged BPF disabled substantially reduce exposure because exploitation then requires elevated capabilities or compromise of a process already allowed to load BPF programs.

How to fix it

Apply a Linux kernel update from the relevant distribution or vendor that includes the upstream fix for the eBPF verifier register delta tracking issue. Because no exact affected product list or fixed package versions were provided, rely on distribution security advisories and kernel changelogs that reference this issue or the fix for linked register delta tracking when src_reg equals dst_reg. Where immediate patching is not possible, reduce exposure by disabling unprivileged eBPF, limiting CAP_BPF, CAP_SYS_ADMIN, and CAP_PERFMON to only trusted processes, enforcing least privilege for containers and service accounts, and using LSM/seccomp/container policy to restrict the bpf() syscall where practical. For container platforms, ensure worker nodes receive the kernel fix; updating userspace packages alone is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, has been updated to a vendor build containing the fix. On Linux systems, compare uname -r and package-manager output against the applicable distribution advisory, then reboot into the fixed kernel if required. Validate that unprivileged eBPF is disabled where it is not explicitly needed by checking /proc/sys/kernel/unprivileged_bpf_disabled; a value that permanently or effectively disables unprivileged BPF reduces exposure. Review process and container capability assignments to ensure only approved software has CAP_BPF, CAP_SYS_ADMIN, or related capabilities. If the vendor provides a regression test, kernel selftest, or BPF verifier test for the linked-register src_reg == dst_reg case, run it against patched systems to confirm the verifier behavior is corrected.

Typical attack path

1. Gain local code execution on a Linux host, for example through a shell, compromised service, container escape prerequisite, or malicious local user account.
2. Determine whether eBPF program loading is permitted via the bpf() syscall, either unprivileged or through granted Linux capabilities.
3. Load a specially crafted eBPF program that triggers the src_reg == dst_reg register tracking corner case in the verifier.
4. Cause the verifier to accept a program whose modeled register bounds or pointer relationships differ from actual runtime behavior.
5. Use the verifier/runtime mismatch to attempt unsafe memory access, kernel memory disclosure, memory corruption, denial of service, or privilege escalation.
6. If successful, obtain higher privileges on the host, disable defenses, access host data, or pivot to other workloads or systems.

How to detect it

There are no unique public indicators in the provided data that reliably identify exploitation of this specific vulnerability. Detection should focus on retrospective signs of suspicious eBPF activity and possible local privilege escalation. Useful sources include Linux audit logs for bpf() syscall use, endpoint telemetry showing bpftool or custom binaries loading BPF programs, kernel logs for verifier errors, crashes, warnings, or oops events near BPF activity, container runtime logs showing privileged containers or added BPF-related capabilities, and EDR telemetry for unexpected processes interacting with /sys/fs/bpf or loading eBPF programs. Investigate BPF program loads by users, services, or containers that do not normally use BPF; BPF activity originating from temporary directories, web service accounts, build jobs, or recently compromised processes is especially suspicious. Also review for post-exploitation behavior such as new root shells, credential access, kernel module tampering, disabled security tools, unexplained persistence, or lateral movement shortly after unusual BPF load events.

What your security team should do

• Identify Linux hosts where unprivileged eBPF is enabled or where workloads have CAP_BPF, CAP_SYS_ADMIN, or CAP_PERFMON, and prioritize those systems for patching.
• Patch and reboot affected Linux systems into a fixed kernel, prioritizing shared, multi-tenant, containerized, CI/CD, developer, and internet-facing infrastructure.
• Disable unprivileged eBPF unless there is a documented business need; treat this as a compensating control but not a substitute for kernel patching.
• Audit container, service, and agent permissions to remove unnecessary BPF-related capabilities and broad privileged-container settings.
• Monitor for unexpected BPF program loads, especially from non-standard processes, user shells, temporary directories, or newly introduced binaries.
• Retain audit, endpoint, and kernel telemetry covering bpf() syscall activity so suspicious BPF program loading can be investigated retrospectively.
• Track vendor advisories because distributions may backport the fix without changing to an obviously newer upstream kernel version.