GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux BPF: dev-bound-only program can attach to a sibling netdev and run driver-specific kfuncs

UnscoredCVE-2026-98382Kernel, userspace & hypervisorcurated

Impact

__bpf_offload_dev_match() fell back to comparing offdev pointers after an exact netdev mismatch, so a device-bound-only program attached on an offload-registered netdev could inherit a real offdev and be accepted on a sibling port. That lets a caller attach a program compiled against one driver's metadata layout to a different driver, where its metadata kfuncs reinterpret that driver's xdp_buff - the reported case runs a veth-bound program on tun and dereferences tun's bare stack xdp_buff as a veth_xdp_buff, giving a general protection fault in interrupt context and a fatal kernel panic. Type-confused reads over driver-private structures are the kind of primitive that does not stay a crash for long. GPU nodes with SR-IOV or offload-capable NICs are exactly the hosts that register offload devices.

Who can reach it

Local, and privileged: the reported path needs CAP_BPF and CAP_NET_ADMIN to call bpf(BPF_LINK_CREATE) with a different target ifindex. Reachable by host-level agents and by any container deliberately given those capabilities plus the host network namespace; not reachable by a standard unprivileged GPU pod.

What to do

Update to a stable kernel carrying the fix (commits in the record) - drain and reboot each node. In the meantime, remove CAP_NET_ADMIN and CAP_BPF from workloads that do not need them, and keep hostNetwork plus those capabilities restricted to CNI and observability components you control.

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.