GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux BPF: link iterator takes a reference to an unsettled link, leading to use-after-free

UnscoredCVE-2026-98378Kernel, userspace & hypervisorcurated

Impact

bpf_link_prime() publishes a link in link_idr before bpf_link_settle() assigns its ID. bpf_link_by_id() skips such ID-zero entries, but the BPF link iterator did not: it took a reference anyway. If anon_inode_getfile() then fails, the creator frees the still-private link and the iterator is left holding a dangling pointer, so its next bpf_link_put() writes to freed memory - KASAN slab-use-after-free, with a kernel panic in the reported trace and the usual escalation potential that comes with a controlled write to a freed slab object. On GPU nodes this matters because BPF is not exotic infrastructure there: Cilium, observability agents and seccomp/LSM tooling all create BPF links, and a crashed or compromised kernel on an accelerator node is the expensive kind of outage.

Who can reach it

Local. The attacker needs to be able to both create BPF links and read the BPF link iterator, which in practice means CAP_BPF/CAP_SYS_ADMIN in the init namespace - not something an ordinary GPU pod has unless it was granted privileged capabilities or host BPF access. The race also needs anon_inode_getfile() to fail, typically forced via fd pressure.

What to do

Update to a stable kernel containing the fix (commits linked in the record); kernel updates mean drain and reboot each node. Until then, the realistic mitigation is to stop granting CAP_BPF/CAP_SYS_ADMIN to tenant workloads and to audit which DaemonSets run with host BPF access.

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.