# CVE-2026-98396: powerpc: Do not restore KUAP in arch_exit_to_user_mode_prepare()

> A logic error in the Linux kernel PowerPC architecture allows premature restoration of user memory access permissions, bypassing Kernel User Access Prevention protections.

- **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:** 14 Oct 2026
- **Updated:** 19 Oct 2026
- **Also known as:** DEBIAN-CVE-2026-98396, GHSA-mcv3-v2qm-396p, UBUNTU-CVE-2026-98396

## What is CVE-2026-98396?

CVE-2026-98396 is a vulnerability in Linux, published on 14 Oct 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:

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

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


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

Apply the vendor's patch.

## Is CVE-2026-98396 being exploited?

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

## Fix prompt for AI coding agents

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

What it is: CVE-2026-98396 is a vulnerability in Linux, published on 14 Oct 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-98396 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-98396/ (Markdown: https://insights.sbomify.com/CVE-2026-98396/index.md)
```

## Sources

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

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