# CVE-2026-72215: MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf()

> A kernel bug causes a hang during boot on MIPS DEC systems if the console driver is not enabled, leading to denial of service.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 15 Aug 2026
- **Updated:** 17 Aug 2026
- **Also known as:** BELL-CVE-2026-72215, DEBIAN-CVE-2026-72215, GHSA-cpm2-25vc-f276, UBUNTU-CVE-2026-72215

## What is CVE-2026-72215?

CVE-2026-72215 is a denial of service vulnerability in Linux, published on 15 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

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.

## Which versions are affected by CVE-2026-72215?


## How do I fix CVE-2026-72215?

Apply the vendor's patch.

## Is CVE-2026-72215 being exploited?

There is no known exploitation of CVE-2026-72215 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-72215 and fix it if it is affected.

What it is: CVE-2026-72215 is a denial of service vulnerability in Linux, published on 15 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-72215 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-72215/ (Markdown: https://insights.sbomify.com/CVE-2026-72215/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-72215
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-72215
- OSV: https://osv.dev/vulnerability/CVE-2026-72215

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-72215/
Summaries are generated and may contain mistakes; the official description above is the record.