CVE-2026-64214

Home/CVE/In the Linux kernel, the following vulnerability has been resolved: powerpc/time: Remove redundant preempt_disable|enab

CVE

↯ PDF report

In the Linux kernel, the following vulnerability has been resolved: powerpc/time: Remove redundant preempt_disable|enab

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].

EPSS 0.00173

EPSS exploitation odds0.17% · top 93%

Monitor

⚠ NVD has not scored this CVE yet - manual triage required (common for recent CVEs)

Sigma rules0 YARA rules0

Look this up elsewhere - one-click external pivots

NVD CVE.org CISA Exploit-DB GitHub PoC VulnCheck KEV GreyNoise

▸ How to read a CVE - triage first, then detect and patch

This page is every public fact about CVE-2026-64214, cross-linked. Its job is to answer one question fast - does this need my attention now? - and then hand you the two things you do about it. Here is how an analyst reads it.

Triage: should I act now? Four signals, and they are not interchangeable:

CVSSseverity - how bad it is IF exploited, 0-10. A high CVSS alone is not urgency; a flaw can be a perfect 10 and never actually be attacked. EPSSprobability - a model’s estimate of the chance it is exploited in the next 30 days, 0-1. This is the “will it actually happen” signal. CISA KEVconfirmed - it is being exploited in the wild right now. The strongest signal on the page; KEV beats any score. Weaponisedavailability - public exploits / PoCs, and especially Metasploit modules rated Excellent / Great. Reliable, packaged exploit code means low-skill attackers can use it today.

How they combine: KEV, or a dependable Metasploit module, means patch now regardless of CVSS. High CVSS + low EPSS + no exploit is real but not an emergency - schedule it. Low CVSS but KEV-listed still gets patched now. The verdict above already weighed these for you; this is how it got there.

Then what - two workflows:

Detectwhen you cannot patch today, follow this CVE to the ATT&CK techniques it enables, then Build a SIEM detection (the green button) - author a rule, test it in Atomic, deploy it. That buys visibility while the patch waits. PatchAffected products / packages tell you if you are exposed; Fixed versions by distribution and Vendor advisories give the exact version that closes it.

Reading order for the panels below: verdict + badges, then Public exploits / Metasploit (is it weaponised), then ATT&CK techniques + Sigma / IDS rules (can I detect it), then Affected products / packages + Fixed versions (am I exposed, what patches it), then Threat actors / IOCs (who uses it), then Scoring & timeline / references (the evidence).

▣

Severity & exploitation scoring

EPSS exploitation probability

0.17%

Top 93%odds of exploitation in the next 30 days

CVSS metric silhouette

No structured CVSS vector for this CVE. Older entries often have only a numeric base score - the metric breakdown radar requires a full AV:_/AC:_/... vector string published by NVD.

SSVC triage

No SSVC vulnrichment for this CVE. CISA's Vulnrichment program scores newer CVEs (~2024 onwards) plus selected older critical ones. Use the EPSS probability + KEV status to triage instead.

🔗

References & Sources

Source URLs (vendor pages, mailing lists, write-ups). Exploit/PoC links are in their own section above to avoid duplication.

https://git.kernel.org/stable/c/31467b23823ffec1f6fff407f8e3ca9af8b7491a

https://git.kernel.org/stable/c/51860e423592893cd7bfa7287d99a3aff4dc3a9d

https://git.kernel.org/stable/c/6dcd072a5ae3aed336e4a67a7d4cc5205b240065

https://git.kernel.org/stable/c/72d8d1c36452a4d3ee134b1da48de7518c1329f9

https://git.kernel.org/stable/c/8079acc5ee5235a627e4586d4f42082a9000ea64

https://git.kernel.org/stable/c/a09d07ac45e283c9861a9ceea06f56d0ba851d22