CVE-2026-53094

What it actually does

This is a Linux kernel use-after-free in the BPF/XDP dev-bound program path. When constant blinding is enabled for BPF JIT hardening, the kernel may clone a dev-bound-only BPF program and free the original program object, but one offload back-pointer can remain pointed at the freed object. Later, when the associated network namespace or network device is cleaned up, the kernel dereferences that stale pointer during BPF offload teardown, causing a kernel page fault. The practical impact is primarily local denial of service through a kernel crash or panic; successful triggering generally requires the ability to load or run the relevant BPF/XDP program workflow and manipulate the associated network namespace/device lifecycle.

Why it matters to the business

Affected Linux systems can crash if the vulnerable BPF/XDP cleanup path is triggered, causing workload interruption, node reboot, failed networking workloads, and potential service availability impact. The risk is lower than remotely exploitable flaws because exploitation requires local capabilities related to BPF, XDP, network namespaces, or privileged container/network operations. It is not listed in CISA KEV, has no known ransomware association, no known public exploit maturity in the provided data, and has a low EPSS score, so remediation should be handled through normal kernel maintenance unless the environment heavily uses BPF/XDP, privileged containers, custom networking stacks, or automated network namespace creation.

How an attack unfolds

An attacker or untrusted local workload first needs sufficient privileges or delegated capabilities to enable or rely on hardened BPF JIT behavior, create a network namespace and virtual network device, and load a dev-bound-only XDP/BPF program. With BPF JIT constant blinding enabled, the BPF program is cloned during compilation and the original program object is freed. Because one offload structure still references the freed program object, the attacker then tears down the network namespace or otherwise causes network-device unregister cleanup. During cleanup, the kernel walks the dev-bound BPF program structures and calls the BPF offload destruction path using the stale pointer, resulting in a page fault in kernel context. In typical circumstances this produces a denial-of-service condition rather than reliable code execution.

How to fix it

Apply a Linux kernel update that includes the upstream fix for this BPF offload pointer synchronization bug. Where vendor kernels are used, install the relevant distribution-provided kernel security or stability update rather than attempting to cherry-pick patches manually. If immediate patching is not possible, reduce exposure by restricting untrusted access to BPF and XDP functionality, limiting privileged containers, disabling or tightly controlling unprivileged user namespaces where operationally feasible, and ensuring only trusted administrators can create network namespaces, veth devices, or load BPF programs. As a temporary risk reduction, review whether BPF JIT hardening settings are required in combination with workloads that use dev-bound-only XDP programs; however, do not weaken hardening globally without a documented risk decision because it may reduce protection against other BPF-related attacks.

How to confirm the fix worked

Confirm the running kernel build includes the vendor fix for this issue using the distribution package changelog, advisory metadata, or kernel commit history. Validate that systems have rebooted into the updated kernel, not merely installed it. On Linux hosts, compare `uname -r` with the fixed kernel package version provided by the vendor, and verify package manager output such as `rpm -q --changelog kernel`, `dnf updateinfo`, `apt changelog linux-image-*`, or the equivalent platform tooling. For exposure assessment, check whether BPF JIT hardening is enabled with `/proc/sys/net/core/bpf_jit_harden`, whether workloads are allowed to load BPF/XDP programs, and whether privileged containers or network-namespace-heavy workloads are present. In test environments only, a regression test should exercise dev-bound XDP/BPF program attach and network namespace teardown under BPF JIT hardening and confirm no kernel oops occurs.

Typical attack path

1. Gain local execution in a context with permissions to create network namespaces/devices and load or attach BPF/XDP programs.
2. Ensure BPF JIT constant blinding is enabled, such as net.core.bpf_jit_harden set to 2 or higher.
3. Create a network namespace and a network device such as a veth pair.
4. Load and attach a dev-bound-only XDP/BPF program to the device.
5. Allow the BPF JIT path to clone the program while leaving the offload back-pointer stale.
6. Delete the network namespace or unregister the network device.
7. Trigger BPF offload cleanup, causing the kernel to dereference the freed program pointer and crash.

How to detect it

Look for evidence of prior exploitation or triggering in kernel logs, persistent journal entries, crash dumps, and host monitoring telemetry. Relevant sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, kernel crash dump directories such as `/var/crash`, kdump/vmcore records, and EDR telemetry for BPF/XDP tooling or namespace operations before a crash. Focus on kernel oops or panic messages that show page faults in `__bpf_prog_offload_destroy`, `bpf_dev_bound_netdev_unregister`, `__bpf_offload_dev_netdev_unregister`, `unregister_netdevice_many_notify`, or `cleanup_net`. Correlate crashes with recent creation/deletion of network namespaces, veth devices, XDP program attachment, BPF selftests, container start/stop bursts, or privileged workloads invoking BPF loaders. Also review sysctl history or configuration management records for `net.core.bpf_jit_harden=2`, since that setting is part of the known trigger path. Absence of these artifacts does not prove the flaw was not reachable, but repeated crashes with this call trace are strong evidence of triggering.

• BUG: unable to handle page fault for address:
• RIP: 0010:__bpf_prog_offload_destroy
• __bpf_prog_offload_destroy+0xc/0x80
• __bpf_offload_dev_netdev_unregister
• bpf_dev_bound_netdev_unregister
• unregister_netdevice_many_notify
• cleanup_net+0x21a/0x320
• Workqueue: netns cleanup_net
• net.core.bpf_jit_harden=2
• /proc/sys/net/core/bpf_jit_harden
• echo 2 > /proc/sys/net/core/bpf_jit_harden
• ./test_progs -t xdp_metadata
• xdp_metadata
• BPF_F_XDP_DEV_BOUND_ONLY

What your security team should do

• Prioritize patching Linux systems that run container platforms, CNI/networking components, eBPF/XDP observability tools, packet processing, or workloads with privileged network namespace access.
• Confirm all patched systems have rebooted into the fixed kernel version.
• Restrict BPF program loading to trusted administrative users and trusted platform components.
• Audit privileged containers and workloads granted capabilities such as CAP_BPF, CAP_NET_ADMIN, CAP_SYS_ADMIN, or broad device/network namespace privileges.
• Monitor for kernel oops or panic events referencing BPF offload cleanup, XDP, network namespace cleanup, or `__bpf_prog_offload_destroy`.
• Treat unexpected crashes on multi-tenant or container hosts as potentially security-relevant until kernel logs and workload activity are reviewed.
• Because this issue is not in KEV, has no known ransomware linkage, and has low EPSS in the provided data, schedule remediation according to standard kernel patch cycles unless exposure to BPF/XDP or privileged containers is high.