CVE-2026-53106

What it actually does

This is a Linux kernel denial-of-service flaw in the eBPF local storage deletion path. When BPF local storage elements are deleted from an NMI or certain reentrant contexts, the kernel can enter a deadlock while deferring memory release through RCU-related mechanisms such as kfree_rcu(), call_rcu(), or call_rcu_tasks_trace(). Successful exploitation can stall kernel execution, trigger watchdog or RCU stall conditions, and require a reboot to recover. The issue is not described as enabling privilege escalation, code execution, or data disclosure.

Why it matters to the business

A successful attack can make affected Linux systems hang or become unavailable, disrupting workloads, containers, network services, or infrastructure components running on those hosts. The current public exploitation signal is low: EPSS is 0.001, it is not listed in CISA KEV, it is not associated with ransomware use, and no mature public exploit is indicated. Risk is highest for systems where untrusted users, containers, agents, or workloads can load or trigger eBPF programs.

How an attack unfolds

An attacker first needs a path to execute eBPF code on the target system, typically through local access, a compromised workload, excessive container privileges, CAP_BPF, CAP_SYS_ADMIN, or enabled unprivileged BPF. The attacker then loads or triggers a BPF program that uses BPF local storage deletion helpers in an execution context where deletion is unsafe, such as an NMI context. When the helper attempts to unlink and defer freeing the local storage element, the kernel can deadlock in the RCU/freeing path. The result is a denial of service: CPU stalls, hung tasks, kernel watchdog messages, service unavailability, and potentially a forced reboot.

How to fix it

Apply the vendor-provided Linux kernel update that includes the upstream fix preventing BPF local storage deletion helpers from proceeding in NMI context. Because no exact fixed package versions were provided, use the relevant distribution security advisory or kernel changelog for the deployed kernel branch. Until patching is complete, reduce exposure by disabling unprivileged BPF where feasible, limiting CAP_BPF and CAP_SYS_ADMIN to trusted principals only, avoiding privileged containers unless required, enforcing seccomp/AppArmor/SELinux policies that restrict BPF use, and reviewing observability or networking agents that load custom BPF programs. Reboot into the patched kernel after installation; installing a kernel package alone is not sufficient if the running kernel is unchanged.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated to a build containing the fix. On Linux systems, compare `uname -r` and package manager output against the distribution advisory for this issue. Verify unprivileged BPF posture with `/proc/sys/kernel/unprivileged_bpf_disabled` where applicable. Review container runtime and service configurations for unnecessary privileged mode, CAP_BPF, CAP_SYS_ADMIN, or broad BPF permissions. In non-production environments, validate that BPF programs or agents that use local storage continue to operate after the update and that attempts to delete BPF local storage from unsafe contexts fail cleanly rather than causing stalls.

Typical attack path

1. Obtain local code execution or control of a privileged workload on a Linux host.
2. Gain the ability to load or trigger eBPF programs, for example through CAP_BPF, CAP_SYS_ADMIN, privileged container settings, or unprivileged BPF if enabled.
3. Create or use BPF local storage associated with supported kernel objects.
4. Trigger a BPF program in an NMI or reentrant context that calls a BPF local storage delete helper.
5. Cause the kernel to enter a deadlock or stall in the deferred freeing path.
6. Maintain or repeat the condition until the host becomes unresponsive or requires reboot.

How to detect it

There are no known CVE-specific file artifacts or network indicators for this issue. To assess possible prior exploitation, review kernel logs, system journals, crash dumps, and monitoring data for unexplained hangs, watchdog resets, RCU stalls, soft lockups, or hung tasks occurring shortly after BPF program load, update, attach, or delete activity. Useful log sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, audit logs for `bpf()` syscall activity, eBPF agent logs, container runtime logs, and EDR telemetry showing capability use such as CAP_BPF or CAP_SYS_ADMIN. Correlate suspicious events with local users, containers, or services that loaded BPF programs before the stall. Because the expected effect is denial of service rather than persistence or data theft, absence of durable artifacts does not rule out exploitation.

• watchdog: BUG: soft lockup
• BUG: soft lockup
• INFO: task
• blocked for more than
• rcu: INFO: rcu_preempt detected stalls
• rcu: INFO: rcu_sched detected stalls
• rcu: Stall ended before state dump start
• NMI watchdog: Watchdog detected hard LOCKUP
• kernel: bpf
• audit: BPF
• syscall=bpf
• unprivileged_bpf_disabled

What your security team should do

• Prioritize patching internet-facing, multi-tenant, container-hosting, CI/CD runner, Kubernetes node, and shared Linux systems where less-trusted users or workloads may execute code.
• Inventory systems that permit BPF usage, including hosts with CAP_BPF, CAP_SYS_ADMIN, privileged containers, unprivileged BPF enabled, or kernel observability agents using eBPF.
• Disable unprivileged BPF unless there is a documented business requirement.
• Restrict privileged containers and remove CAP_BPF/CAP_SYS_ADMIN from workloads that do not explicitly need them.
• Monitor kernel logs for RCU stalls, soft lockups, NMI-related warnings, and repeated BPF activity preceding host hangs or reboots.
• Coordinate kernel updates with reboot windows and verify systems actually booted into patched kernels.
• Treat unexplained host hangs on BPF-enabled systems as potentially security-relevant until logs and workload activity are reviewed.