# CVE-2026-98395: powerpc/entry: Fix irq_soft_mask corruption on replayed interrupt exit

> A flaw in the Linux kernel's PowerPC interrupt handling can cause a kernel warning and potential system instability during interrupt replay, leading to denial of service.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Not stated
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 14 Oct 2026
- **Updated:** 19 Oct 2026
- **Also known as:** DEBIAN-CVE-2026-98395, GHSA-c6r3-334m-j754, UBUNTU-CVE-2026-98395

## What is CVE-2026-98395?

CVE-2026-98395 is a denial of service vulnerability in Linux, published on 14 Oct 2026. 

### Official description

In the Linux kernel, the following vulnerability has been resolved:

powerpc/entry: Fix irq_soft_mask corruption on replayed interrupt exit

When __replay_soft_interrupts() replays a pending interrupt (e.g.
PACA_IRQ_DEC -> timer_interrupt), it calls the handler directly with a
synthetic pt_regs. The DEFINE_INTERRUPT_HANDLER_ASYNC wrapper around
each handler calls arch_interrupt_async_exit_prepare() on the way out,
which calls arch_interrupt_exit_prepare() -> local_irq_disable() ->
arch_local_irq_disable(), which does:

    irq_soft_mask_set(IRQS_DISABLED)   /* 0x1 */

This unconditionally overwrites irq_soft_mask with IRQS_DISABLED (0x1),
stripping the IRQS_PMI_DISABLED (0x2) bit. The result is that
irq_soft_mask is 0x1 instead of IRQS_ALL_DISABLED (0x3) when the
handler returns to __replay_soft_interrupts().

For a normally-taken interrupt this is harmless: the next interrupt
always enters through arch_interrupt_enter_prepare() which
unconditionally sets irq_soft_mask to IRQS_ALL_DISABLED. But during
replay, next_interrupt() is called directly between replayed handlers
without going back through arch_interrupt_enter_prepare(), so the
stripped bit is never restored. next_interrupt() then fires a WARNING:

    WARNING: arch/powerpc/kernel/irq_64.c:75
    WARN_ON(irq_soft_mask_return() != IRQS_ALL_DISABLED)

The warning was observed early in boot on a POWER10 pseries guest
during kmem_cache_init_late(), where a spinlock release triggers
interrupt replay that processes a pending timer interrupt.

Debugger state confirming the bug:
  Before timer_interrupt(&regs):
    irq_soft_mask = 0x3 (IRQS_ALL_DISABLED)   correct
    irq_happened  = 0x41 (HARD_DIS|REPLAYING)  correct
  After timer_interrupt(&regs) returns:
    irq_soft_mask = 0x1 (IRQS_DISABLED)        WRONG - PMI bit stripped
    irq_happened  = 0x41                        unchanged

The fix is to replace local_irq_disable() with hard_irq_disable().

hard_irq_disable() is the right primitive here for two reasons:

1. On PPC64 (hw_irq.h:301) it calls irq_soft_mask_set_return(IRQS_ALL_DISABLED),
   setting the soft mask to 0x3 (both IRQS_DISABLED and IRQS_PMI_DISABLED),
   which preserves the PMI bit and fixes the WARNING. The additional
   work it does (__hard_irq_disable(), PACA_IRQ_HARD_DIS |=) is
   redundant but safe since both are already set at this point in the
   exit path; the trace_hardirqs_off() inside is guarded by
   if (!arch_irqs_disabled_flags(flags)) so it will not double-fire.

2. On PPC32 (hw_irq.h:467) hard_irq_disable() maps to
   arch_local_irq_disable() -> __hard_irq_disable(), which clears
   MSR[EE] in hardware. This is exactly correct: PPC32 has no soft-mask
   PACA mechanism, so the hardware disable is the right way to satisfy
   irqentry_exit()'s requirement. This also fixes a build error on PPC32
   where irq_soft_mask_set() is only defined under CONFIG_PPC64:

       arch/powerpc/include/asm/entry-common.h:273: error: implicit
       declaration of function 'irq_soft_mask_set'

   Using hard_irq_disable() requires no #ifdef and is consistent with
   how the rest of the entry code (e.g. entry-common.h:463) handles the
   same PPC32/PPC64 split.

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


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

Apply the vendor's patch.

## Is CVE-2026-98395 being exploited?

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

## Fix prompt for AI coding agents

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

What it is: CVE-2026-98395 is a denial of service vulnerability in Linux, published on 14 Oct 2026. 
Exploitation: There is no known exploitation of CVE-2026-98395 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-98395/ (Markdown: https://insights.sbomify.com/CVE-2026-98395/index.md)
```

## Sources

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

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