CVE-2026-64214

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

powerpc/time: Remove redundant preempt_disable|enable() calls from arch_irq_work_raise()

A kernel panic is observed when handling machine check exceptions from

real mode.

BUG: Unable to handle kernel data access on read at 0xc00000006be21300

Oops: Kernel access of bad area, sig: 11 [#1]

MSR: 8000000000001003 <SF,ME,RI,LE> CR: 88222248 XER: 00000005

CFAR: c00000000003ffc4 DAR: c00000006be21300 DSISR: 40000000 IRQMASK: 0

NIP [c000000000029e40] arch_irq_work_raise+0x10/0x70

LR [c00000000003ffc8] machine_check_queue_event+0xa8/0x150

Call Trace:

[c0000000179d3c70] [c00000000003ff64] machine_check_queue_event+0x44/0x150

[c0000000179d3d30] [c0000000000084e0] machine_check_early_common+0x1f0/0x2c0

The crash occurs because arch_irq_work_raise() calls preempt_disable()

from machine check exception (MCE) handlers running in real mode. In

this context, accessing the preempt_count can fault, leading to the panic.

The preempt_disable()/preempt_enable() pair in arch_irq_work_raise()

was originally added by commit 0fe1ac48bef0 ("powerpc/perf_event: Fix

oops due to perf_event_do_pending call") to avoid races while raising

irq work from exception context.

Later, commit 471ba0e686cb ("irq_work: Do not raise an IPI when

queueing work on the local CPU") added preemption protection in

irq_work_queue() path, while commit 20b876918c06 ("irq_work: Use per

cpu atomics instead of regular atomics") added equivalent

protection in irq_work_queue_on() before reaching arch_irq_work_raise():

irq_work_queue() / irq_work_queue_on()

-> preempt_disable()

-> __irq_work_queue_local()

-> irq_work_raise()

-> arch_irq_work_raise()

As a result, callers other than mce_irq_work_raise() already execute

with preemption disabled, making the additional

preempt_disable()/preempt_enable() pair in arch_irq_work_raise()

redundant.

The arch_irq_work_raise() function executes in NMI context when called

from MCE handler. Hence we will not be preempted or scheduled out since

we are in NMI context with MSR[EE]=0. Therefore, it is safe to remove

the preempt_disable()/preempt_enable() calls from here.

Remove it to avoid accessing preempt_count from real mode context.

[Maddy: Fixed the commit title]