CVE-2026-64214

What it actually does

This is a Linux kernel denial-of-service flaw affecting PowerPC systems in the machine check exception handling path. When a machine check exception is handled from real mode, arch_irq_work_raise() can call preempt_disable()/preempt_enable(), which accesses preempt_count in a context where that access can fault. The result is a kernel oops or panic rather than successful exception handling. The issue is reliability-impacting rather than a typical memory-corruption or privilege-escalation primitive: the primary technical consequence is host crash and forced reboot when the vulnerable code path is reached.

Why it matters to the business

An affected PowerPC Linux system can unexpectedly crash when it encounters the triggering machine check path, causing service interruption, workload failure, and potential loss of in-memory state. The risk is highest for organizations running Linux on PowerPC hardware for business-critical workloads, especially where unplanned reboots affect availability commitments. This CVE is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so remediation should be prioritized based on PowerPC exposure and uptime requirements rather than broad internet exploitation risk.

How an attack unfolds

An attacker would need a way to cause or influence a machine check exception on an affected PowerPC Linux system so that the kernel enters the real-mode MCE handler and queues IRQ work. In the vulnerable kernel, that path reaches arch_irq_work_raise(), which redundantly disables preemption and accesses preempt_count. Because the handler is executing in real/NMI-like context, that access can fault, producing an oops or kernel panic. In practical terms, exploitation is expected to be environment- and hardware-dependent and is more plausible from a local, privileged, hardware-adjacent, or fault-injection position than as a remote network attack. Successful exploitation results in denial of service through a system crash.

How to fix it

Upgrade to a Linux kernel version or vendor-maintained kernel package that includes the PowerPC time/IRQ work fix removing the redundant preempt_disable()/preempt_enable() calls from arch_irq_work_raise(). Because no specific affected product list or fixed package versions were provided, use the relevant Linux distribution, appliance, or platform vendor advisory to identify the corrected kernel build for PowerPC systems. Where immediate patching is not possible, reduce exposure by limiting untrusted local access, restricting privileged hardware/performance interfaces, disabling unnecessary low-level diagnostic access, ensuring crash recovery is automated, and scheduling maintenance windows for high-availability failover. Mitigations do not fully remove the risk because the vulnerable code is in kernel exception handling.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package includes the upstream PowerPC arch_irq_work_raise() fix and that the system has rebooted into the patched kernel, not merely installed it. Validate with vendor package metadata, kernel changelogs, or source inspection showing the redundant preempt_disable()/preempt_enable() calls are absent from arch/powerpc/kernel/time.c in arch_irq_work_raise(). Check uname -a and distribution package tools to ensure the active kernel matches the fixed package. Review recent kernel logs, persistent journal, pstore, and crash dump records for prior oops or panic traces involving arch_irq_work_raise(), machine_check_queue_event(), or machine_check_early_common().

Typical attack path

1. Identify a Linux system running on affected PowerPC hardware and a vulnerable kernel build.
2. Obtain a position from which machine check exceptions can be triggered or influenced, such as local privileged access, hardware-adjacent access, fault injection capability, or another path that can induce relevant hardware error handling.
3. Trigger conditions that cause the kernel to enter the machine check exception handler in real mode.
4. Cause the MCE handling path to queue IRQ work and reach arch_irq_work_raise().
5. The vulnerable kernel accesses preempt_count from an unsafe context, causing a fault.
6. The system logs an oops or panics, resulting in denial of service and possible reboot.

How to detect it

To determine whether this issue has already been triggered, review kernel logs and crash artifacts rather than web or application logs. Useful sources include dmesg output, systemd journal kernel facility entries, /var/log/kern.log, /var/log/messages, /var/crash, kdump vmcores, pstore/ramoops records, hypervisor hardware event logs, service processor logs, rasdaemon records, and machine check reporting tools. Look for kernel oops or panic records on PowerPC systems where the call trace includes arch_irq_work_raise(), machine_check_queue_event(), or machine_check_early_common(), especially with messages such as 'Unable to handle kernel data access', 'Kernel access of bad area', or machine check exception handling. Correlate the timestamp of any crash with system reboots, HA failovers, hardware error reports, service processor events, or local privileged activity. Because there are no public threat actors or exploit campaigns associated with this CVE in the provided data, detection should focus on crash forensics and recurring availability events rather than known attacker infrastructure.

• BUG: Unable to handle kernel data access on read
• Oops: Kernel access of bad area
• Kernel access of bad area
• arch_irq_work_raise
• machine_check_queue_event
• machine_check_early_common
• mce_irq_work_raise
• NIP [*] arch_irq_work_raise
• LR [*] machine_check_queue_event
• CFAR: c00000000003ffc4
• DAR: c00000006be21300
• DSISR: 40000000
• MSR: 8000000000001003
• /var/crash
• /sys/fs/pstore
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Inventory Linux systems running on PowerPC architecture and identify their active kernel versions.
• Prioritize patching for PowerPC systems supporting production, high-availability, or latency-sensitive workloads where kernel panic would create material business impact.
• Apply the vendor-provided fixed kernel and reboot into it; verify the running kernel is the patched version.
• Enable or confirm persistent kernel crash logging, kdump, pstore/ramoops, and centralized collection of kernel logs for affected systems.
• Search historical logs and crash dumps for machine check exception traces involving arch_irq_work_raise(), machine_check_queue_event(), or machine_check_early_common().
• Restrict untrusted shell access and privileged hardware-management capabilities on affected systems until patched.
• Ensure services on affected systems have restart, failover, or cluster recovery procedures in place to reduce downtime from a crash.
• Monitor vendor advisories for exact fixed package versions if using downstream distribution or appliance kernels.