CVE-2026-53095

What it actually does

This is a Linux kernel eBPF verifier/attachment flaw involving kprobe and freplace programs. Uprobe programs may legitimately modify struct pt_regs, but because uprobes are represented internally as KPROBE-type programs, an attacker with permission to load and attach eBPF programs could attach a freplace program to a kprobe program and inherit an unsafe kprobe_write_ctx capability. When the kprobe runs on a kernel function, the replacement program can modify CPU register state, including kernel function arguments, before execution continues. Depending on the chosen kernel function, this can corrupt kernel control flow, force invalid arguments, cause denial of service, bypass security checks, or potentially contribute to local privilege escalation.

Why it matters to the business

Systems that allow untrusted or weakly restricted users, containers, agents, or workloads to load eBPF programs are at the greatest risk. Successful exploitation could let a local attacker tamper with kernel execution, crash production hosts, or potentially gain elevated privileges, which can affect service availability and host integrity. The currently provided EPSS score is low and the issue is not listed in CISA KEV, but kernel privilege-escalation bugs should still be prioritized on multi-tenant Linux systems, container hosts, Kubernetes nodes, developer workstations, and environments where eBPF observability or security tooling is widely used.

How an attack unfolds

An attacker first obtains local code execution on a Linux host with sufficient privileges to create eBPF programs, such as CAP_BPF, CAP_SYS_ADMIN, or access to unprivileged BPF if enabled. They load a KPROBE-type eBPF program and attach it to a selected kernel function. They then load a freplace eBPF program that targets the kprobe program but abuses a mismatch in kprobe_write_ctx handling. When the probed kernel function is invoked, the freplace program modifies struct pt_regs, altering arguments passed to the kernel function. By choosing sensitive kernel functions and controlled register mutations, the attacker may destabilize the kernel, bypass checks, or build a larger exploit chain for privilege escalation. There is no public exploit maturity indicated in the input, so defenders should treat this as a plausible local post-compromise technique rather than confirmed widespread exploitation.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the fix preventing freplace attachment to kprobe programs when kprobe_write_ctx values differ. If exact package versions are not available, track the vendor advisory for CVE-2026-53095 and upgrade to the first fixed kernel release or later. Reboot systems after installing the fixed kernel so the running kernel is replaced. As interim mitigation, restrict eBPF program loading to trusted administrators only, disable unprivileged BPF where feasible, minimize CAP_BPF and CAP_SYS_ADMIN assignment, review container runtimes and workloads for excessive Linux capabilities, and use lockdown, LSM, seccomp, or policy controls to reduce access to the bpf syscall.

How to confirm the fix worked

Confirm the running kernel version, not only the installed package version, is at or above the vendor-fixed release. Validate that unprivileged BPF is disabled unless explicitly required by checking kernel policy such as kernel.unprivileged_bpf_disabled. Use bpftool or equivalent administrative tooling to inventory loaded BPF programs and ensure no unexpected kprobe/freplace programs are present. Where safe in a test environment, verify the patch behavior by attempting to attach a freplace program to a kprobe program with incompatible kprobe_write_ctx semantics; a fixed kernel should reject the attachment rather than allow register modification. Confirm all hosts have been rebooted after patching.

Typical attack path

1. Gain local execution on a Linux system, container host, or workload node.
2. Verify the ability to load and attach eBPF programs through the bpf syscall or helper tooling.
3. Create a KPROBE-type eBPF program attached to a kernel function of interest.
4. Create a freplace eBPF program that attaches to the kprobe program.
5. Use the freplace program to modify struct pt_regs values, such as kernel function arguments.
6. Trigger the target kernel function so the modified register state affects execution.
7. Leverage the resulting corruption, bypass, or crash for denial of service or as part of a local privilege-escalation chain.

How to detect it

Look for evidence of unusual eBPF program loading and attachment before patching. Relevant telemetry sources include Linux audit logs for the bpf syscall, EDR process and syscall telemetry, bpftool output, kernel logs, container runtime logs, Kubernetes audit logs, sudo/session logs, and shell history on systems where administrative users may run BPF tooling. Hunt for BPF_PROG_LOAD and BPF_LINK_CREATE operations by unexpected users or processes, especially programs of type kprobe or extension/freplace attachment. Review loaded BPF programs with bpftool prog show, bpftool link show, and bpftool perf show; investigate unnamed, recently loaded, non-agent-owned, or kprobe-attached programs. Correlate suspicious BPF activity with kernel oops/panic messages, unexplained service crashes, privilege changes, or processes gaining elevated capabilities. Because no specific public exploit artifacts are provided, detection should focus on behavioral evidence of unauthorized eBPF use rather than fixed file hashes or network indicators.

• BPF_PROG_LOAD
• BPF_LINK_CREATE
• BPF_PROG_TYPE_KPROBE
• BPF_PROG_TYPE_EXT
• BPF_TRACE_FREPLACE
• attach_type freplace
• freplace
• kprobe
• bpftool prog load
• bpftool prog attach
• bpftool link create
• kernel.unprivileged_bpf_disabled = 0
• unprivileged_bpf_disabled=0
• cap_bpf
• CAP_BPF
• cap_sys_admin
• CAP_SYS_ADMIN
• /sys/fs/bpf
• /proc/sys/kernel/unprivileged_bpf_disabled

What your security team should do

• Prioritize patching internet-facing, multi-user, container-hosting, Kubernetes, CI/CD, and shared developer Linux systems.
• Immediately audit which users, services, containers, and agents have CAP_BPF, CAP_SYS_ADMIN, privileged container mode, or access to load eBPF programs.
• Disable unprivileged BPF unless there is a documented business requirement.
• Inventory loaded eBPF programs across Linux fleets using bpftool or EDR telemetry and investigate unexpected kprobe or freplace programs.
• Add audit or EDR monitoring for bpf syscall activity, especially BPF_PROG_LOAD, BPF_LINK_CREATE, kprobe attachment, and freplace attachment events.
• Review observability and security agents that legitimately use eBPF and ensure they are vendor-supported and up to date.
• Treat suspicious BPF loading followed by kernel instability, privilege changes, or container escape indicators as high priority.