CVE-2026-98396: powerpc: Do not restore KUAP in arch_exit_to_user_mode_prepare()
In the Linux kernel, the following vulnerability has been resolved:
powerpc: Do not restore KUAP in archexittousermodeprepare()
KUAP means kernel cannot touch user memory unless it explicitly is enabled. In the kernel it should stay AMRKUAPBLOCKED. While returning to userspace just before RFI, kernel should restore the user AMR value back.
Looks like GENERICENTRY might be treating archexittousermodeprepare() as the last architecture step before returning to userspace. commit bee25f97ad24 ("powerpc: Enable GENERICENTRY feature") therefore called kuapuserrestore() from that hook. But on PowerPC that is too early. After irqentryexit() / syscallexittousermode() we still run platform specific exit routines.
e.g. code snippets showing both exception handling and system call handling as the callers of function archexittousermodeprepare() which does kuapuserrestore(). The below path shows that calling kuapuserrestore() is too early when called from archexittousermodeprepare().
Exception handling in exceptions-64s.S =======================================
bl CFUNC(dopagefault) ..DEFINEINTERRUPTHANDLERASYNC(dopagefault) archinterruptasyncenterprepare(regs); state = irqentryenter(regs); instrumentationbegin(); irqenterrcu(); handler(regs); napadjustreturn(regs); irqexitrcu(); instrumentationend(); archinterruptasyncexitprepare(regs); irqentryexit(regs, state); <<< too early irqentryexittousermode() exittousermodeprepare(regs, EXITTOUSERMODEWORKIRQ); archexittousermodeprepare(regs, tiwork); <<< too early b interruptreturnsrr .. bl CFUNC(interruptexituserprepare) <<< already calls kuapuserrestore
prepirqforenabledexit() retry can run kernel code with IRQs on. So only when that routine is fully finished is when the user KUAP should be fully restored which interruptexituserprepare() already takes care of before returning.
Similarly for system call handling in interrupt64.S ======================================================
bl CFUNC(systemcallexception)
.Lsyscallexit: addi r4,r1,STACKINTFRAMEREGS li r5,0 / !scv / bl CFUNC(syscallexitprepare) .. kuapassertlocked(); syscallexittousermode(regs); <<< too early syscallexittousermodeprepare(regs); <<< too early kuapuserrestore(regs); <<< already calls
syscallexitprepare(), which can enable IRQs, replay a pending interrupt, and only then rfi. Those functions already restore KUAP immediately before rfi.
Note that if we restore the user AMR too early like in the current code as shown from the code snippets above, then we get the following warning when CONFIGPPCKUAPDEBUG is enabled: WARNING: arch/powerpc/include/asm/book3s/64/kup.h:293 at interruptexituserprepare+0x1a0/0x1c0 Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected) TRAP: 0700 LR: c00000000000d8d4 CTR: c0000000021fe500 MSR: <SF,EE,ME,IR,DR,RI,LE> CR: 44000804 XER: 20040000 interruptexituserprepare+0x1a0/0x1c0 interruptreturnsrruser+0x8/0x12c
Affected Software
Event History
Frequently Asked Questions
Which systems are affected by this issue?
The issue is specific to the PowerPC architecture in the Linux kernel. The provided information does not identify particular kernel versions or PowerPC platforms.
What condition makes exploitation possible?
The problem occurs on return-to-userspace paths where KUAP restores the user AMR value too early, before PowerPC-specific exit routines have finished. This can leave the kernel able to access user memory when KUAP should remain blocked.
Is a default configuration known to be affected?
The affected condition is associated with PowerPC support for the GENERIC_ENTRY feature and the early call to kuap_user_restore() from arch_exit_to_user_mode_prepare(). The provided data does not state whether this configuration is enabled by default.
What should administrators do?
Apply a Linux kernel update containing the referenced stable commits. The provided information does not describe a temporary mitigation or configuration-based workaround.