Look up another CVE · open CVE-2026-90217 in the interactive tracker
CVE-2026-90217
bpf: Compare iterator types during state pruning
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem kernel/bpf. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-90217 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
An iterator stack slot can be MEM_RCU or PTR_UNTRUSTED. These states must not be equal, or the verifier can prune an unsafe path. Compare the pointer type for STACK_ITER slots.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
kernel/bpf/states.c
- What this is
- BPF [GENERAL] (Safe Dynamic Programs and Tools)MAINTAINERS section matched on kernel/bpf/ · bpf@vger.kernel.org · Supported
Check it on the machine
grep -wE 'CONFIG_BPF|CONFIG_BPF_SYSCALL' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release with an answer below compiles the affected file into the kernels it ships. The build rule could not be established for 2 releases, so nothing is claimed about those.
- bookworm, trixie?
- forky, sidy
- ?
- not established - no Makefile entry for the affected file
- y
- built into the kernel image on every flavour - only a patch removes it
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switches
- CONFIG_BPF, CONFIG_BPF_SYSCALL
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- kernel/bpf
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.7 | 6.18.57 | e4ab436d5ba6 |
| 6.7 | 7.2.6 | 6424b9cde9ed |
| 6.7 | 7.3 | 83608e303b95 |
Why the CNA scored it this way
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 the BPF instruction stream copied in bpf_prog_load() from bpf(2) BPF_PROG_LOAD (__sys_bpf). bpf_check() then stacksafe() treats STACK_ITER slots with MEM_RCU and PTR_UNTRUSTED as equal; that bytecode is local syscall input, not a remote protocol payload.
- AC:LAttack complexity, low
- The attacker authors both verifier paths as in iter_tasks_rcu_state_pruning: bpf_iter_task_new under bpf_rcu_read_lock, then a bpf_get_prandom_u32 branch that nested-lock/unlock (MEM_RCU) or unlock/relock (PTR_UNTRUSTED) before bpf_iter_task_next. Both sides and the branch are attacker-controlled; no victim timing is required.
- PR:LPrivileges required, low
- add_subprog_and_kfunc() rejects kfunc calls unless env->bpf_capable. bpf_iter_task_new and bpf_iter_css_new are kfuncs; BPF_PROG_TYPE_SYSCALL (always sleepable) needs only bpf_token_capable(CAP_BPF). bpf_token_capable() uses ns_capable() on a delegated token userns, so this is not init-namespace root.
- UI:NUser interaction, none
- The attacker loads the crafted sleepable program with BPF_PROG_LOAD and executes it via BPF_PROG_TEST_RUN (bpf_prog_test_run_syscall) or by attaching their own fentry.s; no other user must mount a filesystem, open a file, or cooperate.
- S:UScope, unchanged
- A pruned bpf_iter_task_next() walks host task_struct lists in the same kernel that loaded the program. That is in-kernel use-after-free and privilege escalation, not a KVM/Xen guest-to-host escape or IOMMU bypass.
- C:HConfidentiality impact, high
- After the pruned unlock/relock gap, bpf_iter_task_next() returns kit->pos from bpf_iter_task_kern, a task_struct * that may already have been RCU-freed. The program can read BTF fields of that dangling pointer, so the UAF is an arbitrary kernel disclosure.
- I:HIntegrity impact, high
- bpf_iter_task_next() then calls next_task()/__next_thread() (list_entry_rcu on tasks.next and thread_node) using the dangling kit->pos. Walking attacker-reclaimed task_struct list nodes is a kernel write primitive; UAF and iterator type confusion are Integrity High.
- A:HAvailability impact, high
- Using the untrusted STACK_ITER after the RCU gap makes next_task() or css_next_descendant_*() dereference a freed task_struct or cgroup_subsys_state, causing a kernel oops or panic even when the UAF is not fully exploited.