CVE-2026-90317

What it actually does

The flaw allows a use-after-free when a sleepable BPF program releases the final RCU-protected context via bpf_spin_unlock(); the verifier fails to invalidate associated kptrs, permitting a pointer to reference a freed object on another CPU.

Why it matters to the business

Local attackers can trigger kernel memory corruption leading to crashes, privilege escalation, or data exposure on any system running affected kernels with unprivileged BPF access enabled; the issue affects broad Linux distributions and embedded devices but carries low immediate exploitation likelihood.

How an attack unfolds

An attacker loads a capability-limited sleepable BPF program that acquires a spin lock protecting a kptr, releases the lock to end RCU protection, then dereferences the now-stale pointer in __bpf_get_task_stack or similar helpers, causing a use-after-free on a freed task_struct when another CPU reclaims the object.

How to fix it

Upgrade to a kernel containing the fix that records RCU context before unlock and invalidates pointers only on final exit from protected sections; rebuild and redeploy any custom BPF programs after the update.

How to confirm the fix worked

Confirm the running kernel version contains the RCU-context tracking change in the BPF verifier; exercise sleepable programs that acquire and release spin locks while monitoring for use-after-free warnings in dmesg or with KASAN builds.

Typical attack path

1. Obtain local unprivileged access on a system permitting sleepable BPF programs.
2. Load a crafted BPF program that uses bpf_spin_lock/unlock around a kptr.
3. Trigger the final unlock to drop RCU protection while leaving the pointer valid.
4. Force concurrent freeing of the underlying object from another CPU.
5. Dereference the dangling pointer to achieve use-after-free.

How to detect it

Review kernel logs for use-after-free reports involving __bpf_get_task_stack or BPF spin-lock paths; inspect audit logs for unexpected BPF program loads by non-root users and correlate with any subsequent kernel oops or panic events.

What your security team should do

• Apply the upstream kernel fix immediately on all systems exposing unprivileged BPF.
• Audit and restrict unprivileged BPF usage via sysctl or LSM policies where possible.
• Monitor for future kernel updates and test in staging environments before broad rollout.
• Enable kernel hardening features such as lockdown mode on high-value hosts.