Early KUAP restore in PowerPC kernel exit path
Key facts
- Attack vector
- —
- Privileges required
- —
- User interaction
- —
- Attack complexity
- —
- Impact type
- —
- Confidentiality · integrity · availability
- —
- Fix status
- Fixed
No CVSS vector from any source. Fix status from CNA.
Summary
In the Linux kernel from 7.2, the PowerPC exit path restores the user KUAP access state in arch_exit_to_user_mode_prepare() before the platform exit routines have finished. Kernel code can then run with user memory access enabled while interrupts may still be handled or replayed, which triggers a warning when CONFIG_PPC_KUAP_DEBUG is enabled.
Written with Claude Haiku 5.5 from the sources below · 2026-11-06
Description from the CNA
In the Linux kernel, the following vulnerability has been resolved: powerpc: Do not restore KUAP in arch_exit_to_user_mode_prepare() KUAP means kernel cannot touch user memory unless it explicitly is enabled. In the kernel it should stay AMR_KUAP_BLOCKED. While returning to userspace just before RFI, kernel should restore the user AMR value back. Looks like GENERIC_ENTRY might be treating arch_exit_to_user_mode_prepare() as the last architecture step before returning to userspace. commit bee25f97ad24 ("powerpc: Enable GENERIC_ENTRY feature") therefore called kuap_user_restore() from that hook. But on PowerPC that is too early. After irqentry_exit() / syscall_exit_to_user_mode() we still run platform specific exit routines. e.g. code snippets showing both exception handling and system call handling as the callers of function arch_exit_to_user_mode_prepare() which does kuap_user_restore(). The below path shows that calling kuap_user_restore() is too early when called from arch_exit_to_user_mode_prepare(). Exception handling in exceptions-64s.S ======================================= bl CFUNC(do_page_fault) ..DEFINE_INTERRUPT_HANDLER_ASYNC(do_page_fault) arch_interrupt_async_enter_prepare(regs); state = irqentry_enter(regs); instrumentation_begin(); irq_enter_rcu(); handler(regs); nap_adjust_return(regs); irq_exit_rcu(); instrumentation_end(); arch_interrupt_async_exit_prepare(regs); irqentry_exit(regs, state); <<< too early irqentry_exit_to_user_mode() __exit_to_user_mode_prepare(regs, EXIT_TO_USER_MODE_WORK_IRQ); arch_exit_to_user_mode_prepare(regs, ti_work); <<< too early b interrupt_return_srr .. bl CFUNC(interrupt_exit_user_prepare) <<< already calls kuap_user_restore prep_irq_for_enabled_exit() 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 interrupt_exit_user_prepare() already takes care of before returning. Similarly for system call handling in interrupt_64.S ====================================================== bl CFUNC(system_call_exception) .Lsyscall_exit: addi r4,r1,STACK_INT_FRAME_REGS li r5,0 /* !scv */ bl CFUNC(syscall_exit_prepare) .. kuap_assert_locked(); syscall_exit_to_user_mode(regs); <<< too early syscall_exit_to_user_mode_prepare(regs); <<< too early kuap_user_restore(regs); <<< already calls syscall_exit_prepare(), 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 CONFIG_PPC_KUAP_DEBUG is enabled: WARNING: arch/powerpc/include/asm/book3s/64/kup.h:293 at interrupt_exit_user_prepare+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 interrupt_exit_user_prepare+0x1a0/0x1c0 interrupt_return_srr_user+0x8/0x12c
Why it matters now
SSVC decision points
Not available: CISA has not published SSVC decision points for this record.
Affected products
Remediation
Upgrade the Linux kernel to 7.2.7 or 7.3.
Written with Claude Haiku 5.5 from the sources below · 2026-11-06
- Fix · CNA Linux (Linux) Fixed in 7.2.7, 7.3
Vendor assessments
Red Hat
Red Hat rating: Moderate. Red Hat's page for this CVE →
Not affected: 7 products
- Red Hat Enterprise Linux 10
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 7
- Red Hat Enterprise Linux 8
- Red Hat Enterprise Linux 9
- Red Hat OpenShift Container Platform 4
- Red Hat OpenShift Container Platform 5
Timeline
- 2026-10-14 Threatist record created from CVE-2026-98396
- 2026-10-14 Alias added: GHSA-mcv3-v2qm-396p
- 2026-10-16 Affected versions changed · Red Hat
- 2026-10-16 CVSS score added · Red Hat
- 2026-10-19 Fix available: Linux/[email protected] · CNA
- 2026-11-06 Affected versions changed · Red Hat
References
More Linux vulnerabilities
- TI-2025-26358 tls: fix handling of zero-length records on the rx_list KEVCVSS 3.1CRITICAL 9.8
- TI-2026-38352 netfilter: bridge: make ebt_snat ARP rewrite writable KEVCVSS 3.1HIGH 8.8
- TI-2021-02452 Incorrect authorization in Ubuntu linux kernel KEVCVSS 3.1HIGH 8.8
- TI-2013-05264 The (1) get_user and (2) put_user API functions in the Linux kernel before 3.5.5 on the… KEVCVSS 3.1HIGH 8.8
- TI-2022-00125 Integer overflow in kernel KEVCVSS 3.1HIGH 8.4
- TI-2013-01864 The perf_swevent_init function in kernel/events/core.c in the Linux kernel before 3.8.9… KEVCVSS 3.1HIGH 8.4
Sources
- CVE-2026-98396 · CVE Program
- CVE-2026-98396 · NVD
- FIRST EPSS
- GHSA-mcv3-v2qm-396p · GitHub Advisory Database · CC BY 4.0
- CVE-2026-98396 · Red Hat security data · CC BY 4.0
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences