Linux kernel on POWER hash MMU: stale hardware SLB entries cause an SLB multi-hit machine check

CVSS 7.8CVE-2025-71078Kernel, userspace & hypervisorcurated

Impact

On POWER hosts using the hash MMU, the kernel skips switch_mmu_context() when the previous and next mm_struct match. If a process's SLB entry is evicted from the software preload cache on one CPU and the process is then scheduled on another CPU without a context switch, the hardware SLB keeps stale entries; reloading one triggers an SLB multi-hit, which on POWER is a machine check and takes the host down. For an operator that means an unscheduled node loss - on a GPU node mid-training, the whole job's rank set goes with it. The trigger is ordinary scheduling behaviour, so this can also fire without an attacker, and the upstream record describes availability impact rather than a path to code execution. Only POWER systems on the hash MMU are affected; radix-MMU and non-POWER hosts are not.

Who can reach it

Local - an unprivileged process on an affected POWER host, through normal exec and CPU migration. No special capability or device access needed, and no network path.

What to do

Take the stable kernel update that fixes the preload-cache and hardware SLB divergence; the fix is backported across five stable branches covering 4.20 through 6.19. Rollout is drain, install kernel, reboot. There is no runtime toggle; switching a host from hash to radix MMU avoids the path but is not a patch-equivalent change to make under time pressure.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-71078 https://git.kernel.org/stable/c/00312419f0863964625d6dcda8183f96849412c6 https://git.kernel.org/stable/c/895123c309a34d2cfccf7812b41e17261a3a6f37

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.