CVE-2026-90317

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

The attacker-controlled input is a sleepable BPF program loaded via bpf(BPF_PROG_LOAD) whose bytecode reaches process_spin_lock() in kernel/bpf/verifier.c, takes bpf_spin_lock, LDXes a map kptr, then bpf_spin_unlock. That program image arrives through the local bpf() syscall, not a network protocol message.

AC:LAttack complexity, low

The attacker drives both sides: a sleepable fentry.s or BPF_PROG_TYPE_SYSCALL program loads a task kptr under bpf_spin_lock, unlocks, then uses it, while another thread bpf_kptr_xchg's the same slot to NULL so bpf_task_release_dtor/put_task_struct_rcu_user can call_rcu it. After unlock, preempt/IRQs are re-enabled so the grace period can finish; a PoC hit the UAF.

PR:LPrivileges required, low

A sleepable BPF_PROG_TYPE_SYSCALL program is sufficient: bpf_prog_load() requires only bpf_token_capable(CAP_BPF) because is_perfmon_prog_type() is false for SYSCALL, and map_check_btf() needs CAP_BPF for BPF_SPIN_LOCK|BPF_KPTR fields. CAP_BPF is delegable via BPF tokens into a user namespace; the report used a capability-limited PoC, not init-namespace root.

UI:NUser interaction, none

The attacker loads the sleepable program, creates the lock+kptr ARRAY map, stores a task with bpf_task_from_pid/bpf_kptr_xchg, and runs it via bpf(BPF_PROG_TEST_RUN) (bpf_prog_test_run_syscall) or by calling getpgid after attaching fentry.s; no victim mount or file open is required.

S:UScope, unchanged

The use-after-free is of a host kernel task_struct consumed by bpf_task_acquire and __bpf_get_task_stack in the same kernel that accepted the program. That is local privilege escalation inside one kernel authority, not a VM, IOMMU, or guest-to-host crossing.

C:HConfidentiality impact, high

After the final bpf_spin_unlock, process_spin_lock() leaves the map-loaded task kptr as MEM_RCU, so the program can LDX task_struct fields or call bpf_task_acquire (refcount_inc_not_zero on rcu_users) and __bpf_get_task_stack (try_get_task_stack/task_pt_regs) on a call_rcu-freed object. Spraying that slot yields an arbitrary kernel read.

I:HIntegrity impact, high

The same stale MEM_RCU task_struct pointer can be passed to bpf_task_acquire after bpf_task_release_dtor has dropped rcu_users and delayed_put_task_struct has freed it; a sprayed replacement becomes an owned kptr the attacker can feed to other kfuncs or store back with bpf_kptr_xchg, giving a write and control-flow primitive.

A:HAvailability impact, high

Using the dangling task pointer in __bpf_get_task_stack (try_get_task_stack/task_pt_regs) or bpf_task_acquire after put_task_struct_rcu_user's call_rcu has run oopses or panics the kernel even without a full exploit.