CVE-2026-90393: bpf: Fix potential UAF in bpf_netns_link_update_prog
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix potential UAF in bpfnetnslinkupdateprog
In bpfnetnslinkupdateprog, the checks for oldprog and prog type are currently performed locklessly before acquiring netnsbpfmutex. This creates a race condition that can lead to a UAF issue.
If two threads concurrently execute BPFLINKUPDATE on the same netns link, the following execution path can trigger a UAF:
CPU0 CPU1 bpfnetnslinkupdateprog if (oldprog && oldprog != link->prog) return -EPERM; bpfnetnslinkupdateprog if (oldprog && oldprog != link->prog) ... oldprog = xchg(&link->prog, newprog); bpfprogput(oldprog); if (newprog->type != link->prog->type) <-- trigger UAF
Fix this by moving the oldprog and prog->type checks inside the netnsbpfmutex critical section. Meanwhile, use guard() to simplify lock management and avoid all the goto jumping.
Event History
Frequently Asked Questions
Which systems are exposed to this race condition?
Systems are exposed when two threads can concurrently execute BPF_LINK_UPDATE against the same network-namespace BPF link. The affected path is specifically the network-namespace link program update operation.
What condition is required to trigger the use-after-free?
Two concurrent updates must target the same netns link. One update can replace and release the existing program while the other thread performs the program-type check using the stale link->prog reference.
What does the fix change?
The fix moves the old-program validation and program-type checks into the netns_bpf_mutex critical section. This serializes those checks with program replacement and release operations.