CVE-2026-53096
HighCVSS 7.8Exploitation Probability (EPSS)
Low risk3th percentile - higher than 3% of all known CVEs
Summary
A vulnerability was found in the Linux kernel's dev_map_redirect_multi() function for the SKB path in BPF. Using unsafe hlist_for_each_entry_safe() instead of hlist_for_each_entry_rcu() can cause data races on weakly-ordered architectures (ARM64, POWER).
Risk Assessment
The organization is at risk of reading incomplete or corrupted data during BPF packet redirection, potentially leading to unpredictable system behavior or network data integrity issues.
Recommendation
Immediately update the Linux kernel to a version containing the fix that replaces the unsafe iteration with an RCU-safe one and corrects the lockdep condition.
Original NVD description (English source)
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.