CVE-2026-64214 in Linux
Summary
by MITRE • 07/24/2026
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]
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/24/2026
The vulnerability under analysis involves a kernel panic occurring in the Linux powerpc architecture when handling machine check exceptions from real mode contexts. This issue stems from redundant preempt_disable() and preempt_enable() calls within the arch_irq_work_raise() function, which creates an improper access to kernel data structures during exception handling. The crash manifests as a data access fault at address 0xc00000006be21300 with a kernel access violation signal 11, indicating that the system cannot handle the memory access properly when executing in real mode context.
The technical flaw arises from the improper handling of preemption control during machine check exception processing. When arch_irq_work_raise() is invoked from machine check exception handlers running in real mode, it attempts to access preempt_count which causes a fault due to the inconsistent state of the kernel's preemption subsystem. The original implementation added preempt_disable()/preempt_enable() pairs to prevent races while raising irq work from exception context, specifically addressing issues related to perf_event_do_pending calls as documented in commit 0fe1ac48bef0. However, subsequent commits have already introduced preemption protection at higher levels of the call stack.
The operational impact of this vulnerability is significant as it can cause complete system crashes during machine check exception handling, which are critical error conditions that typically indicate hardware failures or severe system instability. The vulnerability specifically affects systems running on powerpc architecture when machine check exceptions occur in real mode contexts. This represents a direct violation of the kernel's stability requirements and can lead to unexpected system termination during error recovery procedures.
The root cause analysis reveals that preemption protection has been moved up the call stack through commits 471ba0e686cb and 20b876918c06, making the additional preempt_disable()/preempt_enable() calls in arch_irq_work_raise() redundant. The function executes within NMI context where preemption is already disabled due to MSR[EE]=0, eliminating the need for explicit preemption control. This vulnerability aligns with CWE-367 weakness classification related to Time-of-Check to Time-of-Use (TOCTOU) errors and represents a specific instance of improper resource management in kernel exception handling pathways.
The recommended mitigation involves removing the redundant preempt_disable() and preempt_enable() calls from arch_irq_work_raise() function, which directly addresses the root cause by eliminating access to preempt_count from real mode contexts. This solution follows established security practices for kernel development and aligns with ATT&CK technique T1547.001 related to registry run keys and persistence mechanisms while specifically addressing kernel-level memory access violations. The fix ensures that machine check exception handlers can properly process errors without triggering kernel panics, thereby improving system stability during critical error recovery scenarios.
This vulnerability demonstrates the importance of proper preemption management in kernel code and highlights how redundant protection mechanisms can create unexpected side effects. The fix represents a standard kernel security update that addresses improper memory access patterns and prevents unauthorized kernel state modifications during critical exception handling procedures. The solution maintains all necessary protection mechanisms while eliminating the problematic code path that causes system crashes, ensuring that machine check exceptions can be properly handled without compromising system stability or security.