CVE-2026-46290: Linux Kernel x86/EFI DoS Vulnerability

CVE-2026-46290 Overview

CVE-2026-46290 is a Linux kernel vulnerability in the x86 Extensible Firmware Interface (EFI) runtime services path. A prior change to kernel_fpu_begin() switched fpregs_lock() from preempt_disable() to local_bh_disable(), which sets SOFTIRQ_OFFSET in preempt_count for the duration of EFI runtime service calls. This causes in_interrupt() to return true in normal task context, breaking the graceful page fault handler efi_crash_gracefully_on_page_fault(). On systems with buggy firmware that faults during EFI runtime calls such as GetTime(), the kernel calls panic("Fatal exception in interrupt") instead of recovering with EFI_ABORTED, producing a hard system freeze.

Critical Impact

Systems with buggy firmware experience unrecoverable hangs during EFI runtime calls instead of graceful recovery, resulting in denial of service.

Affected Products

• Linux kernel x86 architecture builds with EFI runtime services
• Kernels including commit d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs")
• Systems running EFI firmware that may trigger page faults during runtime service calls

Discovery Timeline

• 2026-06-08 - CVE-2026-46290 published to NVD
• 2026-06-08 - Last updated in NVD database

Technical Details for CVE-2026-46290

Vulnerability Analysis

The vulnerability stems from an interaction between the FPU subsystem and the EFI runtime services fault handler [Kernel Vulnerability]. Commit d02198550423 changed kernel_fpu_begin() so that fpregs_lock() calls local_bh_disable() instead of preempt_disable(). This change sets the SOFTIRQ_OFFSET bit in preempt_count during the entire EFI runtime service call.

The graceful fault handler efi_crash_gracefully_on_page_fault() relies on in_interrupt() to detect whether a fault occurred in real interrupt context. With SOFTIRQ_OFFSET set, in_interrupt() returns true even though the call originates from a normal task. The handler therefore bails out and the fault escalates to die(), which also observes in_interrupt() as true and invokes panic("Fatal exception in interrupt").

Root Cause

The root cause is incorrect context detection in efi_crash_gracefully_on_page_fault(). The handler assumed in_interrupt() reflected only hardware or NMI context, but the FPU lock change made local_bh_disable() a normal part of EFI runtime call paths. The check no longer distinguishes between firmware-induced faults in task context and genuine interrupt context faults.

Attack Vector

This is a reliability and denial-of-service issue triggered by firmware behavior rather than a remote attack primitive. On affected systems with buggy UEFI firmware, accessing unmapped memory during routine EFI runtime calls such as GetTime() causes a kernel panic and hard freeze. Recovery requires a power cycle. The fix replaces in_interrupt() with !in_task(), which incorporates in_serving_softirq() and correctly identifies hardware interrupt and NMI contexts without misclassifying the softirq-disabled task context introduced by fpregs_lock().

No verified public exploit code is available. Refer to the upstream commits for the technical fix details.

Detection Methods for CVE-2026-46290

Indicators of Compromise

• Kernel panic messages containing the string Fatal exception in interrupt following EFI runtime service calls.
• System log entries referencing efi_crash_gracefully_on_page_fault immediately before a hard hang.
• Repeated unexplained hard freezes correlated with EFI services such as GetTime(), SetVariable(), or GetVariable().

Detection Strategies

• Inventory running kernel versions and identify builds containing commit d02198550423 but lacking the fix commits referenced in the kernel git log.
• Correlate firmware vendor and version data with crash telemetry to identify systems with buggy EFI implementations.
• Review dmesg and kdump artifacts after unexpected reboots to confirm whether the panic path matches this signature.

Monitoring Recommendations

• Forward kernel logs to a centralized logging or SIEM platform to detect panic strings and EFI fault patterns at scale.
• Track firmware revisions across the fleet so EFI runtime issues can be isolated to specific hardware models.
• Alert on repeated Fatal exception in interrupt panics tied to EFI call sites.

How to Mitigate CVE-2026-46290

Immediate Actions Required

• Apply the upstream kernel fixes referenced in the Kernel Git Commit Log, Kernel Git Commit Log, and Kernel Git Commit Log.
• Update firmware on affected hardware to vendor-recommended versions that resolve known EFI runtime fault conditions.
• Prioritize patching on systems that have previously panicked during EFI calls or run firmware with known faults in GetTime().

Patch Information

The fix replaces in_interrupt() with !in_task() inside efi_crash_gracefully_on_page_fault(). Using !in_task() correctly covers hardware interrupt, NMI, and softirq-serving contexts while excluding the softirq-disabled task context that fpregs_lock() now produces. Distribution-provided kernel updates that backport the referenced commits remediate the issue.

Workarounds

• Where patching is not immediately possible, work with hardware vendors to update UEFI firmware so runtime services do not access unmapped memory.
• Avoid kernel configurations that rely on the affected EFI runtime call paths in production until updated kernels are deployed.
• Maintain serial console or out-of-band management access to capture panic output and accelerate diagnosis when freezes occur.

# Verify the running kernel version and check for the fix
uname -r
# Inspect kernel log for prior EFI panic signatures
journalctl -k | grep -E "efi_crash_gracefully_on_page_fault|Fatal exception in interrupt"