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.

bash

# 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"