GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel XDP: BPF_LINK_UPDATE bypasses offload checks, putting a device-bound program on the software path

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

Impact

bpf_xdp_link_update() called dev_xdp_install() directly instead of going through dev_xdp_attach(), so the checks that reject offloaded, device-bound, wrong-device, DEVMAP and CPUMAP programs never ran. A caller could create an XDP link with an ordinary program and then swap in an offloaded or device-bound program with BPF_LINK_UPDATE, running it on the generic software path it was never verified for. On GPU fleet nodes this is the data-plane path: XDP is commonly used for load balancing, DDoS filtering and RDMA-adjacent packet steering on high-rate NICs, so running a device-bound program in the wrong context can corrupt packet handling or crash the host networking stack on a node that cannot be drained cheaply. NVD scores it local, low complexity, high across confidentiality, integrity and availability.

Who can reach it

Local user with the capability to create and update BPF links on the host network namespace (effectively CAP_BPF/CAP_NET_ADMIN or root). Not reachable from an unprivileged tenant pod unless the pod has been granted those capabilities.

What to do

Apply the stable kernel update that moves the program checks into dev_xdp_install() (commits 03022dd87407, 486dbe7efec2, ad27ed7d2309, ea7b35dcc943) and reboot each node; the fix is in built-in core networking code with no module-reload or live-patch option in the record. Until then, do not grant CAP_BPF or CAP_NET_ADMIN on the host network namespace to workloads. No fixed release numbers are given in the record.

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.