CVE-2026-93259 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
powerpc/irq: Fix missing r2 clobber in PCREL inline assembly
In CONFIG_PPC_KERNEL_PCREL mode, r2 is no longer reserved for the TOC pointer and is available as a caller-saved register [0].
Both call_do_irq() and call_do_softirq() use inline assembly to call functions with stack switching, but fail to list r2 in their clobber lists. This causes the compiler to assume r2 is preserved across these calls, leading to register corruption when the called functions (__do_irq and __do_softirq) clobber r2.
As a result of this kernel crash during interrupt handling is seen and the kernel fails to boot:
BUG: Unable to handle kernel data access on write at 0xc000000404697638 Faulting instruction address: 0xc0000000000181ec Oops: Kernel access of bad area, sig: 11 [#1]
NIP [c0000000000181ec] __do_IRQ+0x6c/0xc0
With older GCC, the compiler would conservatively allocate callee-saved registers (like r31) for values spanning function calls, accidentally avoiding the bug:
<__do_IRQ>: 00 00 00 60 nop a6 02 08 7c mflr r0 f8 ff e1 fb std r31,-8(r1) f0 ff c1 fb std r30,-16(r1) 2d 03 10 06 pla r31,53297316
...
3d e8 ff 4b bl c0000000000165ac <__do_irq> 00 00 21 e8 ld r1,0(r1) 28 00 4d e9 ld r10,40(r13) 40 00 21 38 addi r1,r1,64 2a f9 aa 7f stdx r29,r10,r31
With newer GCC 14, the compiler uses r2 for such values, exposing the missing clobber specification:
<__do_IRQ>: 00 00 00 60 nop a6 02 08 7c mflr r0 f0 ff c1 fb std r30,-16(r1) f8 ff e1 fb std r31,-8(r1) 29 02 10 06 pla r2,36252592 # c0000000022aadc0 <__irq_regs>
...
85 dc ff 4b bl c000000000015ee0 <__do_irq> 00 00 21 e8 ld r1,0(r1) 28 00 2d e9 ld r9,40(r13) 30 00 21 38 addi r1,r1,48 2a 11 c9 7f stdx r30,r9,r2
Fix this by adding r2 to the clobber list for both call_do_irq() and call_do_softirq() when CONFIG_PPC_KERNEL_PCREL is enabled.
[0]: https://www.mail-archive.com/[email protected]/msg313226.html
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel contains a critical register corruption vulnerability within the powerpc interrupt handling subsystem, specifically affecting configurations where CONFIG_PPC_KERNEL_PCREL is enabled. This architectural mode alters the calling convention for PowerPC processors by no longer reserving register r2 for the Table of Contents pointer, thereby making it available as a caller-saved register that may be modified by function calls without preservation requirements. The vulnerability resides in two inline assembly functions, call_do_irq and call_do_softirq, which are responsible for invoking low-level interrupt processing routines such as __do_irq and __do_softirq while managing stack switching operations. These inline assemblies fail to declare r2 in their clobber lists, leading the compiler to incorrectly assume that the value of register r2 remains unchanged across these function calls. This oversight results in severe state corruption because the called functions actively modify r2 for internal purposes, overwriting data that the caller still believes is valid and preserved.
The operational impact of this flaw manifests as immediate kernel instability during interrupt processing sequences. When an interrupt occurs or softirqs are processed under a PCREL configuration with modern compiler toolchains, the corrupted register state leads to invalid memory accesses. The system typically responds with a fatal Oops error indicating a kernel data access violation on write at specific high-memory addresses, followed by a crash within the __do_IRQ function. In severe cases, this corruption prevents the operating system from completing its boot sequence entirely, rendering the affected systems unbootable until the issue is resolved or workarounds are applied. The root cause is directly tied to compiler behavior differences between older and newer versions of GCC. Older compilers tended to conservatively allocate callee-saved registers like r31 for values spanning function calls, which inadvertently masked the missing clobber specification by avoiding the use of r2 for critical state preservation during these specific inline assembly blocks.
With the release of GCC version 14 and other modern compiler updates, the optimization strategies changed significantly regarding register allocation in PCREL mode. The newer compilers began utilizing r2 to hold values that span function calls within these inline assemblies, directly exposing the missing clobber declaration. This shift means that while older toolchains might have produced working binaries by accident due to conservative register usage patterns, modern builds are highly susceptible to this bug. The vulnerability represents a classic case of incorrect assembly constraint specification where the compiler's assumptions about register preservation conflict with actual hardware behavior and callee-side modifications.
From a security taxonomy perspective, this issue aligns closely with CWE-471, which describes modification of assumed immutable data, as well as CWE-362 regarding concurrent execution using shared resources without proper synchronization or state management at the architectural level. In terms of attack surface analysis under MITRE ATT&CK, while primarily a stability and reliability flaw rather than an exploitable security vulnerability for remote code execution in this specific context, it relates to T1059 Command Line Interface if one considers how system crashes can be induced via local interrupt flooding or timing attacks on affected systems. The mitigation is straightforward and definitive: developers must update the inline assembly constraints for both call_do_irq and call_do_softirq functions within the powerpc architecture codebase. Specifically, r2 must be added to the clobber list when CONFIG_PPC_KERNEL_PCREL is enabled. This ensures that the compiler correctly identifies r2 as a volatile register in this context and avoids relying on its value after the inline assembly block executes. System administrators should ensure their kernel builds utilize patched source code or update their toolchains if they are using older GCC versions where the bug was masked, though patching the source remains the only permanent solution for modern development environments.