Cloudanix VulnDB

CVE-2026-53096

None

CVSS

—

EPSS

0.1%

Published

Jun 24, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux networking bug can make affected systems unstable or crash when advanced packet-processing features are used under certain conditions.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
High
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Medium

What it actually does

This is a Linux kernel race-condition flaw in the BPF devmap redirect path. The affected code iterates DEVMAP_HASH buckets in softirq/RCU context using a non-RCU-safe list iterator while concurrent updates and deletes use RCU list primitives. On weakly ordered CPU architectures such as ARM64 and POWER, the reader may observe an incompletely initialized or concurrently removed node because the required RCU acquire semantics are missing. The practical result is kernel memory-safety instability in the generic XDP/BPF redirect path, potentially causing crashes, data races, or undefined kernel behavior when BPF devmap hash entries are modified concurrently with packet redirection.

Why it matters to the business

Systems using affected Linux kernels with BPF/XDP devmap hash redirection may be exposed to kernel instability, which can cause service interruption, packet-processing disruption, or host crashes. The current exploitation likelihood appears low: the issue is not in CISA KEV, is not known to be used in ransomware campaigns, has no reported mature public exploit, and has a low EPSS score. Risk is higher for environments that rely on XDP/eBPF networking, high-performance packet processing, container networking, load balancing, DDoS filtering, or ARM64/POWER Linux deployments.

How an attack unfolds

An attacker would need a path to exercise or influence BPF/XDP devmap hash behavior on a vulnerable kernel. In a realistic scenario, this likely requires local privileges or control over a workload that can create or update relevant BPF maps and trigger packet redirection through the generic XDP path. The attacker repeatedly modifies DEVMAP_HASH entries while causing traffic to traverse the redirect path, attempting to win the race between RCU-protected writers and the unsafe reader. On susceptible architectures, this can cause the kernel reader to dereference stale or partially initialized list entries, leading to kernel warnings, crashes, or other unstable behavior. There is no current evidence of broad remote exploitation or named threat actor use.

How to fix it

Upgrade to a Linux kernel version that includes the fix replacing the unsafe hash-list iteration with RCU-safe iteration in the BPF devmap redirect path. If vendor-specific fixed package versions are not available, apply the latest kernel security update from the operating system or appliance vendor and reboot into the patched kernel. Where immediate patching is not possible, reduce exposure by limiting use of untrusted eBPF/XDP workloads, restricting BPF-related capabilities to trusted administrators only, disabling unprivileged BPF where applicable, and avoiding deployment of untrusted workloads with CAP_BPF, CAP_NET_ADMIN, or broad privileged-container permissions. Systems on ARM64 and POWER should be prioritized because the memory-ordering issue is more likely to be observable there.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated by checking the active kernel version after reboot. Validate with the relevant distribution advisory or kernel changelog that the BPF devmap RCU-safe iteration fix is included. Review kernel configuration and runtime controls to confirm unprivileged BPF is disabled where required, and audit container/runtime profiles for unnecessary CAP_BPF, CAP_NET_ADMIN, or privileged mode. For environments using XDP/eBPF networking, run regression tests that exercise devmap hash redirects under traffic and map update/delete activity while monitoring for kernel warnings, lockdep/KCSAN reports, soft lockups, or crashes.

Typical attack path

  1. Gain local code execution or sufficient privileges/capabilities to load or manipulate BPF/XDP programs and devmap hash entries, such as CAP_BPF, CAP_NET_ADMIN, or equivalent container/runtime privileges.
  2. Create or access a BPF DEVMAP_HASH used for XDP/generic redirect behavior.
  3. Generate traffic that triggers xdp_do_generic_redirect_map() and dev_map_redirect_multi() on the vulnerable path.
  4. Concurrently update or delete devmap hash entries while packet redirection is occurring.
  5. Attempt to trigger the unsafe list traversal race, potentially causing kernel memory-safety faults, host instability, or denial of service.

How to detect it

There are no reliable, unique indicators proving exploitation of this flaw. Detection should focus on evidence of suspicious BPF/XDP activity followed by kernel instability. Review kernel logs, system journals, crash dumps, audit logs, eBPF observability logs, container runtime events, and endpoint telemetry for unexpected BPF program loads, devmap/devmap_hash map creation or updates, privileged container execution, or unusual use of BPF-related capabilities before a kernel panic, oops, soft lockup, or networking outage. On systems with auditd or equivalent telemetry, investigate use of bpftool, custom loaders, privileged network namespaces, CAP_BPF, CAP_NET_ADMIN, and rapid BPF map update/delete activity. Correlate any crash stack traces involving BPF, XDP generic redirect, devmap redirect, or dev_map_redirect_multi with recent local administrative activity or untrusted workloads. Because no public exploit pattern or threat actor activity is known, absence of these artifacts does not prove the vulnerability was not triggered.

What your security team should do

  • Prioritize patching Linux systems that use eBPF/XDP, container networking, packet filtering, load balancing, DDoS mitigation, or high-performance network datapaths.
  • Prioritize ARM64 and POWER systems because the race is more relevant on weakly ordered architectures.
  • Restrict BPF and network-administration capabilities to trusted administrators and trusted workloads only.
  • Disable unprivileged BPF where operationally feasible.
  • Review privileged containers and workloads with CAP_BPF, CAP_NET_ADMIN, or full host networking access.
  • Monitor kernel logs for crashes, warnings, lockdep reports, KCSAN reports, or BPF/XDP-related instability until patching is complete.
  • Track vendor advisories for exact fixed kernel package versions and ensure systems reboot into the corrected kernel.

The record

In the Linux kernel, the following vulnerability has been resolved: bpf: Use RCU-safe iteration in dev_map_redirect_multi() SKB path The DEVMAP_HASH branch in dev_map_redirect_multi() uses hlist_for_each_entry_safe() to iterate hash buckets, but this function runs under RCU protection (called from xdp_do_generic_redirect_map() in softirq context). Concurrent writers (__dev_map_hash_update_elem, dev_map_hash_delete_elem) modify the list using RCU primitives (hlist_add_head_rcu, hlist_del_rcu). hlist_for_each_entry_safe() performs plain pointer dereferences without rcu_dereference(), missing the acquire barrier needed to pair with writers' rcu_assign_pointer(). On weakly-ordered architectures (ARM64, POWER), a reader can observe a partially-constructed node. It also defeats CONFIG_PROVE_RCU lockdep validation and KCSAN data-race detection. Replace with hlist_for_each_entry_rcu() using rcu_read_lock_bh_held() as the lockdep condition, consistent with the rcu_dereference_check() used in the DEVMAP (non-hash) branch of the same functions. Also fix the same incorrect lockdep_is_held(&dtab->index_lock) condition in dev_map_enqueue_multi(), where the lock is not held either.

Affected packages

Ecosystem Package Introduced Fixed