Look up another CVE · open CVE-2026-89459 in the interactive tracker
CVE-2026-89459
s390/percpu: Fix MVIY_PERCPU() with older binutils
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem arch/s390. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-89459 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 | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | not affected | 7.2.11-1 | Nothing to do. forky never shipped the vulnerable code. |
| Debian unstablesid | not affected | 7.2.11-1 | Nothing to do. sid never shipped the vulnerable code. |
The vulnerability
What the bug is
Commit a737737cdb9c ("s390/percpu: Infrastructure for more efficient this_cpu operations") introduced MVIY_PERCPU(), which stringifies arguments that are already C string literals. This generates an assembler macro invocation with whitespace-separated quoted arguments: GEN_MVIY "459712" "%r3" GNU as versions prior to binutils 2.39 drop the separating whitespace between quoted macro arguments during input scrubbing. They consequently parse the invocation as a single argument and emit repeated warnings: Warning: missing closing `"' The .ifc in GEN_MVIY never matches and GNU as exits successfully without emitting the mviy instruction. As a result, the interrupted per-CPU sequence is not marked in lowcore and the exception return path cannot repair the per-CPU address register after migration. All MVIY_PERCPU() callers pass C string literals. Use them directly and separate the assembler macro arguments with an explicit comma. The resulting invocation is: GEN_MVIY 459712, %r3 This form is unambiguous for GNU as and LLVM's integrated assembler. This behavior was fixed in GNU as from binutils 2.39, but Linux supports binutils 2.30.
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/s390/include/asm/percpu.h
- What this is
- PER-CPU MEMORY ALLOCATORMAINTAINERS section matched on arch/*/include/asm/percpu.h · linux-mm@kvack.org · Maintained
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid?
- ?
- not established - no Makefile entry for the affected file
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.
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
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 7.0 high
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.14%, higher than 3.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- arch/s390
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 7.2 | 7.2.4 | 91770b08a120 |
| 7.2 | 7.3 | 101782f8945a |
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 omitted mviy start marker is in s390 this_cpu_read/write/add sequences reached from local syscalls (mm/swap, memcg, vmalloc) and user-namespace nftables; this is an arch per-CPU primitive, not a packet parser, ksmbd/nfsd handler, or USB path.
- AC:HAttack complexity, high
- The op is wrong only if an interrupt or preemption and a CPU migration both occur after AG adds the old CPU offset and before the atomic instruction; that one-instruction window is not attacker-timed, even with affinity bouncing on default PREEMPT_LAZY s390.
- PR:LPrivileges required, low
- Any unprivileged local user can drive this_cpu_* via ordinary syscalls, and nft_ct's this_cpu_read(nft_ct_pcpu_template) is reachable with CAP_NET_ADMIN in a user namespace; init-namespace root is not required.
- UI:NUser interaction, none
- The attacker triggers the unmarked this_cpu sequences from their own process (syscalls or locally generated packets); no victim mount, file open, or other interaction is required.
- S:UScope, unchanged
- Stale per-CPU pointers are used inside the same host kernel after migration; this is not a KVM/Xen guest-to-host escape or IOMMU/DMA boundary bypass.
- C:HConfidentiality impact, high
- After migration, this_cpu_read uses another CPU's pointer-typed slots (percpu_swap_cluster.si, nft_ct_pcpu_template, page-pool/socket pointers) without that CPU's locking, which can disclose kernel objects and is memory corruption leverageable for info disclosure.
- I:HIntegrity impact, high
- The matching this_cpu_write/add then mutates the previous CPU's per-CPU state (swap cluster cache, conntrack templates, other CPU-local structures that assume exclusive access), which is kernel memory corruption exploitable toward control-flow hijack.
- A:HAvailability impact, high
- A stale per-CPU pointer after migration can oops or panic (NULL vmalloc ne_fit_preload_node, inconsistent swap_info, conntrack refcount UAF), which is a full kernel availability loss on SMP s390.