CVE-2026-72215

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.