GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux bpf devmap: non-RCU hash iteration in the XDP broadcast redirect path can read a half-built entry

CVSS 7.8CVE-2026-53096Kernel, userspace & hypervisorcurated

Impact

The DEVMAP_HASH branch of dev_map_redirect_multi() walked the hash bucket with hlist_for_each_entry_safe() while running under RCU in softirq context, so it dereferenced pointers without the acquire barrier that pairs with the writers' rcu_assign_pointer(). On weakly-ordered CPUs - arm64 and POWER, which covers Grace and Ampere nodes - a reader can observe a partially constructed devmap entry during an XDP broadcast redirect. It also defeated lockdep RCU validation and KCSAN, so the class of bug was invisible to the usual testing. This path is live on nodes running XDP-based CNI or load balancing (Cilium and similar), where devmap updates happen while traffic is being redirected. The published record is an ordering and annotation fix; it does not demonstrate a working exploit, and reaching it requires the ability to load XDP programs and update devmaps, which is a privileged operation on a normal node.

Who can reach it

Local and privileged in practice - loading XDP/devmap programs and updating devmap entries needs CAP_BPF/CAP_NET_ADMIN. The race is then driven by in-flight network traffic hitting the broadcast redirect while the map is updated.

What to do

Update to a stable kernel that switches to hlist_for_each_entry_rcu() with rcu_read_lock_bh_held() and drops the bogus lockdep_is_held(&dtab->index_lock) condition in dev_map_enqueue_multi(). No userspace workaround beyond not using DEVMAP_HASH broadcast redirect. Drain and reboot nodes, prioritising arm64 and POWER hosts where the missing barrier actually matters.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.