CVE-2026-53089

What it actually does

This is a Linux kernel use-after-free/refcounting flaw in the BPF offload information path. When userspace queries information about an offloaded BPF map or program, the kernel attempts to take a reference on the network namespace associated with the offload device. During concurrent network namespace teardown, that namespace reference count may already be zero; using get_net() in that state can increment a freed object and trigger a refcount warning, kernel fault, or memory-safety failure. The upstream fix replaces get_net() with maybe_get_net(), which only increments the reference count if the object is still alive and otherwise fails safely with -ENOENT.

Why it matters to the business

Successful exploitation could destabilize Linux systems that use BPF offload-capable networking, potentially causing kernel crashes, service interruption, or host reboots. The practical risk is reduced by the race-condition nature of the bug, the need for local interaction with BPF/offload interfaces, and the current absence of known public exploitation, KEV listing, ransomware association, or high EPSS signal. Because the flaw is in the Linux kernel, exposed fleets should still prioritize normal kernel patching, especially on systems with container workloads, network namespace churn, or programmable/offload-capable network devices.

How an attack unfolds

An attacker who can interact with BPF and network namespace functionality prepares or targets a BPF map or program associated with an offload-capable network device. They then create timing pressure by repeatedly querying offloaded BPF object information while another thread or process tears down the related network namespace. If the query path reaches bpf_map_offload_info_fill_ns() or bpf_prog_offload_info_fill_ns() after the namespace reference count has reached zero, the vulnerable kernel may attempt to take a reference on an object that is already being freed. In vulnerable builds this can produce a refcount_t warning, kernel oops, or broader memory corruption condition. Reliable exploitation beyond denial of service is not established from the available information.

How to fix it

Upgrade to a vendor-supported Linux kernel that contains the upstream fix replacing get_net() with maybe_get_net() in the BPF offloaded map/program info fill paths. If exact package versions are not available from the vulnerability metadata, use the fixed kernel versions published by the relevant Linux distribution or appliance vendor. Until patching is complete, reduce exposure by disabling unprivileged BPF where operationally feasible, limiting CAP_BPF/CAP_SYS_ADMIN access, restricting creation of user and network namespaces for untrusted workloads, and disabling or avoiding BPF hardware offload on systems that do not require it. Treat internet-facing services as indirectly affected only if an attacker could first obtain local code execution or container escape-relevant privileges needed to reach these kernel interfaces.

How to confirm the fix worked

Confirm that systems are running a kernel build that includes the BPF offload namespace reference fix. Validate through distribution security advisories, kernel package changelogs, or source inspection for use of maybe_get_net() in bpf_map_offload_info_fill_ns() and bpf_prog_offload_info_fill_ns(). Check exposure by identifying systems with BPF enabled, permissive unprivileged BPF settings, container or network namespace workloads, and NICs/drivers that support BPF offload. After remediation, monitor kernel logs during normal BPF and namespace lifecycle activity to ensure there are no refcount_t warnings, kernel oopses, or stack traces referencing the affected BPF offload functions.

Typical attack path

1. Obtain local ability to use BPF/offload-related kernel interfaces, commonly requiring elevated privileges or permissive BPF configuration.
2. Identify or create an offloaded BPF map or program tied to an offload-capable network device.
3. Trigger repeated userspace information queries against the offloaded BPF object, such as through BPF object info APIs or management tooling.
4. Concurrently create and destroy network namespaces associated with the offload device to race namespace teardown.
5. Win the race where the BPF offload info path accesses the network namespace after its reference count has reached zero.
6. Cause a kernel refcount/use-after-free failure, potentially resulting in kernel warning, oops, crash, or service disruption.

How to detect it

To assess prior exploitation or attempted triggering, review kernel logs, persistent journal entries, crash dumps, and kdump/vmcore records for refcount warnings or oops traces involving BPF offload information functions during network namespace teardown. Relevant sources include dmesg, /var/log/kern.log, /var/log/messages, systemd-journald kernel facility logs, crash dump metadata, and EDR telemetry that captures kernel panic or reboot causes. Look for repeated local activity around BPF object information queries, bpftool usage, namespace creation/destruction, and unexpected host reboots occurring close together. Because the vulnerability is a timing race in kernel memory management, there may be no durable file artifact after a successful crash; absence of logs does not prove absence of attempted exploitation if kernel logs were not persisted across reboot.

• refcount_t: addition on 0; use-after-free
• bpf_map_offload_info_fill_ns
• bpf_prog_offload_info_fill_ns
• refcount_warn_saturate
• ns_get_path_cb
• WARNING: CPU:
• kernel BUG at
• BUG: kernel NULL pointer dereference
• Oops:
• /var/log/kern.log
• /var/log/messages
• /proc/sys/kernel/unprivileged_bpf_disabled

What your security team should do

• Prioritize kernel updates on systems that run containers, frequently create/destroy network namespaces, or use SmartNIC/NIC BPF offload capabilities.
• Disable unprivileged BPF where possible by setting kernel.unprivileged_bpf_disabled to a restrictive value according to distribution guidance.
• Restrict CAP_BPF, CAP_SYS_ADMIN, and network namespace creation to trusted workloads and administrators only.
• Inventory systems with BPF offload-capable devices and validate whether BPF hardware offload is enabled or required.
• Add monitoring for kernel log signatures associated with this bug, including refcount_t warnings and stack traces containing the affected BPF offload functions.
• Because this is not currently KEV-listed, not associated with ransomware, has low EPSS, and has no known exploit maturity, handle through expedited routine patching unless local privilege exposure or BPF offload usage is widespread.