CVE-2026-90393

What it actually does

Race condition in bpf_netns_link_update_prog allows concurrent BPF_LINK_UPDATE operations to bypass old_prog and prog type checks before acquiring netns_bpf_mutex, resulting in a use-after-free when one thread replaces the link program while another still references it.

Why it matters to the business

Systems relying on BPF programs attached to network namespaces risk kernel instability, crashes, or potential privilege escalation; low EPSS and no known exploitation reduce immediate urgency but require patching within standard maintenance windows.

How an attack unfolds

An attacker with local access to issue concurrent BPF_LINK_UPDATE syscalls on the same netns link triggers the race: one thread validates and swaps the program while the other dereferences the freed old_prog after the xchg and bpf_prog_put, leading to UAF.

How to fix it

Apply the upstream Linux kernel fix that moves the old_prog and prog type checks inside the netns_bpf_mutex critical section and adopts guard() for lock management; rebuild and deploy the patched kernel across affected hosts.

How to confirm the fix worked

Confirm the patched kernel source contains the checks inside the mutex and the use of guard(); verify running kernel version incorporates the commit resolving bpf_netns_link_update_prog; run targeted BPF link update concurrency tests to ensure no UAF occurs.

Typical attack path

1. Obtain local execution capability on a system with BPF netns links
2. Identify or create a netns link object usable for BPF_LINK_UPDATE
3. Launch two threads that simultaneously call BPF_LINK_UPDATE with matching old_prog values
4. Trigger the window where one thread performs xchg and bpf_prog_put while the other performs the type check
5. Cause dereference of the freed program pointer resulting in UAF

How to detect it

Inspect kernel logs and dmesg for use-after-free warnings or oops referencing bpf_netns_link_update_prog; correlate with audit records of concurrent BPF_LINK_UPDATE syscalls from the same process or user.

• bpf_netns_link_update_prog
• UAF in bpf_netns_link_update_prog

What your security team should do

• Prioritize kernel updates on systems that actively use BPF programs attached to network namespaces
• Monitor kernel logs for UAF-related oops and stack traces involving bpf_netns_link_update_prog
• Limit unprivileged BPF access where feasible until patches are applied