Look up another CVE · open CVE-2026-89581 in the interactive tracker
CVE-2026-89581
bpf, x86: Fix per-CPU address resolution into an extended register
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem arch/x86. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-89581 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 | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| 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. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
The destination of the per-CPU address MOV is encoded in ModRM.reg, which is extended by REX.R, but the REX prefix is built with add_1mod(), which sets REX.B. REX.B extends ModRM.rm and SIB.base, and this instruction addresses memory as disp32 with no base, so the bit has no effect at all and the high register bit is simply lost. Every is_ereg() destination therefore resolves to the wrong register, picking whichever one shares the low three bits: R5 -> RAX R7 -> RBP R8 -> RSI R9 -> RDI With BPF_REG_5, whose reg2hex is 0, the emitted 65 49 03 04 25 <off> add %gs:<off>,%rax adds the per-CPU offset to RAX rather than R8. The destination keeps the unadjusted address and RAX is clobbered, so the program goes on to dereference a pointer that was never made per-CPU: BUG: unable to handle page fault for address: 0000607e386a8894 RIP: bpf_prog_707837aafd2aa9ae_update_percpu_data+0x93/0xc9 Call Trace: __bpf_prog_test_run_raw_tp+0x2dc/0x7d0 __flush_smp_call_function_queue+0x1e9/0xc80 Kernel panic - not syncing: Fatal exception in interrupt R5 is the mildest of the four, aliasing a scratch register and faulting at the store. R7 aliases RBP and would corrupt the frame pointer, R8 and R9 alias the argument registers. Use add_2mod() so the register goes through REX.R, matching how add_2reg() places it in ModRM.reg and how emit_priv_frame_ptr() hardcodes 0x4c for the same instruction with R9. Encodings for the non-extended registers are unchanged. Problem showed up when trying to resurrect BPF_GCC CI (selftests built with BPF_GCC). This has gone unnoticed because clang reloads the address into R1 before each per-CPU access, so the destination is never an extended register. GCC keeps several per-CPU addresses live at once, and test_progs-bpf_gcc panics the kernel in global_percpu_data/init, where the address of a .percpu variable ends up in R5.
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.
arch/x86/net/bpf_jit_comp.c
- What this is
- BPF JIT for X86 64-BITMAINTAINERS section matched on arch/x86/net/ · bpf@vger.kernel.org · Supported
Check it on the machine
grep -w CONFIG_BPF_JIT /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, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormy
- trixie, forky, sidYnot built on s390x/s390x
- bookworm · linux-6.12y
- y
- built into the kernel image on every flavour - only a patch removes it
- Y
- built in where it is built at all; some flavours do not build it
- Build switch
- CONFIG_BPF_JIT
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-11 (37 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.13%, higher than 2.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- arch/x86
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.10 | 6.12.109 | 638bc3aada8e |
| 6.10 | 6.18.50 | 6886642414f5 |
| 6.10 | 7.2.4 | 6a19b18d4588 |
| 6.10 | 7.3 | 5bbbce02e500 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
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 x86 BPF JIT mis-encodes per-CPU address resolution in do_jit() in arch/x86/net/bpf_jit_comp.c. It is reached only when a local process loads a BPF program that uses .percpu globals or PERCPU_ARRAY direct-value ld_imm64 via bpf(2); kernel CNA guidance classifies BPF as Local.
- AC:LAttack complexity, low
- The attacker chooses the ld_imm64 destination in their own bytecode; bpf_do_misc_fixups() always appends BPF_MOV64_PERCPU_REG on that same register, so targeting an extended register (BPF_REG_5/7/8/9) and hitting the wrong REX prefix is fully attacker-controlled, with no race or layout outside their influence.
- PR:LPrivileges required, low
- Triggering the JIT path requires bpf(BPF_PROG_LOAD) with a PERCPU_ARRAY/.percpu map value (CAP_BPF, plus CAP_PERFMON for tracing types). PERCPU_ARRAY is an unprivileged map type, and CAP_BPF is delegable via BPF tokens/user namespaces, which kernel CNA guidance rates as Low rather than init-namespace root.
- UI:NUser interaction, none
- The attacker loads and runs their own crafted BPF program through bpf(2) (and optionally BPF_PROG_TEST_RUN); no separate victim action such as mounting a filesystem or opening a file is required.
- S:UScope, unchanged
- Wrong-register clobber and mis-resolved per-CPU pointer accesses corrupt memory inside the host kernel. This is standard in-kernel memory corruption/privilege escalation, not a VM escape, IOMMU bypass, or other cross-authority boundary.
- C:HConfidentiality impact, high
- Missing REX.R leaves the destination holding an unadjusted __percpu offset that the verifier still types as a map-value pointer, so later loads read kernel memory at the wrong address; BPF_REG_7 also aliases RBP, sending stack-relative reads elsewhere and yielding a kernel disclosure primitive.
- I:HIntegrity impact, high
- The same mis-resolved pointer is used for verifier-approved map-value stores, and BPF_REG_7 clobbers RBP so subsequent JIT stack spills write to the wrong kernel address; that is attacker-controlled memory corruption exploitable for arbitrary write or control-flow hijack.
- A:HAvailability impact, high
- The mis-encoded add leaves a non-per-CPU pointer that is then dereferenced, causing a kernel page-fault oops/panic (including in interrupt context via bpf_prog_test_run_raw_tp). Kernel CNA guidance rates any such crash as Availability High.