CVE-2026-72215 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf()
In 64-bit configurations calling any firmware entry points from a kernel thread other than the initial one will result in a situation where the stack has been placed in the XKPHYS 64-bit memory segment.
Consequently the stack pointer is no longer a 32-bit value and when the 32-bit firmware code called uses 32-bit ALU operations to manipulate the stack pointer, the calculated result is incorrect (in fact in the 64-bit MIPS ISA almost all 32-bit ALU operations will produce an unpredictable result when executed on 64-bit data) and control goes astray.
This may happen when no final console driver has been enabled in the configuration and consequently the initial console continues being used late into bootstrap, or with an upcoming change that will switch the zs driver to use a platform device, which in turn will make the console handover happen only after other kernel threads have already been started, and the kernel will hang at:
pid_max: default: 32768 minimum: 301
or somewhat later, but always before:
cblist_init_generic: Setting adjustable number of callback queues.
has been printed.
It seems that only the prom_printf() entry point is affected. Of all the other entry points wired only rex_slot_address() and rex_gettcinfo() are called from a kernel thread other than the initial one, specifically kernel_init(), and they are leaf functions that do no business with the stack, having worked with no issue ever since 64-bit support was added for the platform back in 2002.
To address this issue then, arrange for the stack to be switched in the o32 wrapper as required for prom_printf() only, by supplying call_o32() with a pointer to a chunk of initdata space, which is placed in the CKSEG0 32-bit compatibility segment, observing that prom_printf() is only called from console output handler and therefore with the console lock held, implying no need for this code to be reentrant.
Other firmware entry points may be called with interrupts enabled and no lock held, and may therefore require that call_o32() be reentrant. They trigger no issue at this point and "if it ain't broke, don't fix it," so just leave them alone.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability affects the MIPS architecture implementation within the Linux kernel, specifically addressing a critical stack management issue in 64-bit configurations. The problem manifests when firmware entry points are invoked from kernel threads other than the initial one, causing the stack to be positioned within the XKPHYS 64-bit memory segment rather than the expected 32-bit range. This architectural mismatch creates a fundamental conflict where 32-bit ALU operations fail catastrophically on 64-bit data, leading to unpredictable execution paths and system hangs.
The technical flaw stems from the improper handling of stack pointers during firmware calls in 64-bit MIPS environments. When kernel threads other than the initial one execute firmware entry points, the stack pointer becomes a 64-bit value instead of maintaining its expected 32-bit nature. This occurs because the DEC (Distributed Ethernet Controller) implementation does not properly account for the stack segment requirements when transitioning between 32-bit and 64-bit execution contexts. The issue is particularly severe with prom_printf() since it operates within console output handlers where the console lock is held, making reentrancy concerns irrelevant for this specific function.
The operational impact of this vulnerability results in system hangs during early boot sequences, specifically manifesting before critical initialization milestones such as pid_max configuration and callback queue initialization. The vulnerability affects only the prom_printf() entry point among all firmware interfaces, as other functions like rex_slot_address() and rex_gettcinfo() are either called from the initial thread or are leaf functions that do not manipulate stack pointers. This selective impact aligns with CWE-129: Improper Validation of Array Index, though more specifically represents a memory segment validation failure in 64-bit contexts.
The mitigation strategy involves implementing targeted stack switching within the o32 wrapper for prom_printf() only, utilizing initdata space that resides in the CKSEG0 32-bit compatibility segment. This approach addresses the root cause by ensuring proper stack positioning without affecting other firmware entry points that may be called with interrupts enabled and without lock held. The solution leverages the existing console lock mechanism to eliminate reentrancy requirements for prom_printf(), following ATT&CK technique T1059.007: Command and Scripting Interpreter: PowerShell, where specific system functions are isolated rather than broadly patched. This targeted approach maintains system stability while preserving existing functionality for other firmware interfaces that have operated without issues since 2002 when 64-bit support was first introduced. The fix ensures that only the problematic prom_printf() function receives the necessary stack management treatment, avoiding unnecessary performance impacts on other kernel operations.