HIGH Introduced in 5.8
bpf NetnsLink UAF
CVE-2026-90393
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
01Description
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential UAF in bpf_netns_link_update_prog In bpf_netns_link_update_prog, the checks for old_prog and prog type are currently performed locklessly before acquiring netns_bpf_mutex. This creates a race condition that can lead to a UAF issue. If two threads concurrently execute BPF_LINK_UPDATE on the same netns link, the following execution path can trigger a UAF: CPU0 CPU1 bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) return -EPERM; bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) ... old_prog = xchg(&link->prog, new_prog); bpf_prog_put(old_prog); if (new_prog->type != link->prog->type) <-- trigger UAF Fix this by moving the old_prog and prog->type checks inside the netns_bpf_mutex critical section. Meanwhile, use guard() to simplify lock management and avoid all the goto jumping.
02KernelScan AI Analysis
Risk summary
A local attacker with BPF and network namespace capabilities can exploit a race condition in the BPF network namespace link update path to trigger a use-after-free, potentially achieving arbitrary kernel read/write and container escape. Systems that allow unprivileged BPF or run multi-tenant container workloads are at highest risk. The race requires concurrent BPF_LINK_UPDATE calls on the same link, making exploitation non-trivial but feasible.
Vulnerability analysis
A race condition exists in the BPF network namespace link update path where validation checks on the currently attached program are performed without holding the protecting mutex. When two threads concurrently update the same link, one thread can read a stale program pointer while another thread swaps in a replacement and frees the old program, causing the first thread to dereference freed memory. The fix moves all validation checks inside the mutex critical section so they execute atomically with the program swap, eliminating the window where a freed pointer can be accessed. The vulnerable path is reached locally through the bpf() syscall by a process holding BPF and network administration capabilities, which may be obtainable inside a user namespace on systems where unprivileged BPF is not disabled.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 5.10 | 5.8 | 5.10.270 | d462b5481d77 |
| 5.15 | 5.8 | 5.15.221 | bdddf3e1493e |
| 6.1 | 5.8 | 6.1.188 | 79a66fd997d4 |
| 6.12 | 5.8 | 6.12.110 | 277168cb9d15 |
| 6.18 | 5.8 | 6.18.52 | bda86e9f31b9 |
| 6.6 | 5.8 | 6.6.157 | f4ce6803df40 |
| 7.2 | 5.8 | 7.2.6 | 923f559e95b8 |
| mainline | 5.8 | 7.3 | 5c5997836381 |
| cip/5.10 | 5.8 | 5.10.271-cip78 | d462b5481d77 |
| cip/6.1 | 5.8 | 6.1.189-cip61 | 79a66fd997d4 |
| cip/6.1-rt | 5.8 | 6.1.189-cip61-rt32 | 79a66fd997d4 |
| cip/6.12 | 5.8 | 6.12.111-cip32 | 277168cb9d15 |
04CIP Kernels
State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.
| CIP tree | State |
|---|---|
| cip/6.12 | Fixed in 6.12.111-cip32 |
| cip/6.1 | Fixed in 6.1.189-cip61 |
| cip/6.1-rt | Fixed in 6.1.189-cip61-rt32 |
| cip/5.10 | Fixed in 5.10.271-cip78 |
| cip/5.10-rt | Affected — no CIP fix yet (latest 5.10.268-cip77-rt34) |