CVE-2026-89459: s390/percpu: Fix MVIY_PERCPU() with older binutils
In the Linux kernel, the following vulnerability has been resolved:
s390/percpu: Fix MVIYPERCPU() with older binutils
Commit a737737cdb9c ("s390/percpu: Infrastructure for more efficient thiscpu operations") introduced MVIYPERCPU(), which stringifies arguments that are already C string literals. This generates an assembler macro invocation with whitespace-separated quoted arguments:
GENMVIY "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 GENMVIY 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 MVIYPERCPU() callers pass C string literals. Use them directly and separate the assembler macro arguments with an explicit comma. The resulting invocation is:
GENMVIY 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.
Affected Software
Event History
Frequently Asked Questions
Which systems are affected by this issue?
The issue affects s390 Linux kernel builds that use GNU as from binutils versions earlier than 2.39. LLVM's integrated assembler accepts the corrected macro form unambiguously.
What conditions lead to the faulty generated code?
The affected MVIY_PERCPU() call sites pass C string literals that are stringified into whitespace-separated quoted assembler macro arguments. Older GNU as removes the separating whitespace during input scrubbing, treats the arguments as one value, and does not emit the required mviy instruction.
How can I tell whether a build is affected?
An affected GNU as build emits repeated warnings such as "missing closing `\"'" while assembling the macro invocation, but still exits successfully. The GEN_MVIY conditional then does not match and the mviy instruction is absent.
What is the practical consequence of a vulnerable build?
The interrupted per-CPU sequence is not marked in lowcore. If migration occurs, the exception return path cannot repair the per-CPU address register.