CVE-2026-46290: Linux EFI Page Fault Handler Fix for FPU Softirq Regression

Technical summary

The vulnerability stems from commit d02198550423, which replaced preempt_disable() with local_bh_disable() in kernel_fpu_begin() to improve FPU usability in softirq contexts. This change sets SOFTIRQ_OFFSET in preempt_count, causing in_interrupt() to evaluate true even in normal task context. The graceful fault handler efi_crash_gracefully_on_page_fault() relies on in_interrupt() to determine whether to attempt recovery from EFI firmware page faults. With SOFTIRQ_OFFSET now present, the handler incorrectly bails out for all faults occurring during EFI runtime service calls, leaving firmware-induced page faults unhandled. The kernel's die() function then observes in_interrupt() as true and invokes panic(), resulting in an unrecoverable system freeze. The fix replaces in_interrupt() with !in_task(), which incorporates in_serving_softirq() and correctly identifies only genuine interrupt and NMI contexts while allowing graceful EFI fault recovery during the FPU code path.

Business impact

On production systems running Linux on x86/EFI platforms with firmware implementations that trigger page faults during GetTime() or other runtime service calls, this vulnerability causes unpredictable system hangs that cannot be recovered gracefully. This affects availability and may complicate firmware compatibility and system stability in data center and embedded environments where such firmware quirks exist. The issue manifests only on systems with specific buggy firmware, limiting but not eliminating the population at risk.

Affected systems

The vulnerability affects Linux kernel systems on x86/EFI architectures. The condition is triggered by the combination of: (1) kernel versions containing commit d02198550423 or later that modified FPU softirq handling, and (2) EFI firmware implementations that generate page faults during runtime service calls. Systems running older kernels without the FPU softirq optimization commit are not affected. Non-x86 architectures and non-EFI boot paths are unaffected.

Exploitability

This is not a privilege escalation or remote code execution vulnerability. Exploitation requires buggy firmware that generates page faults during EFI runtime calls—a hardware/firmware condition rather than a software input vector. The vulnerability is triggered passively during normal EFI operations, not through intentional attack. No user action or malicious input is required; affected systems hang automatically when firmware generates the fault. However, since it requires specific firmware bugs and kernel versions, practical exploitability is limited to systems with both conditions present.

Remediation

Apply the kernel patch that replaces in_interrupt() with !in_task() in the efi_crash_gracefully_on_page_fault() handler. This fix restores the graceful fault recovery mechanism while preserving the FPU softirq optimization. Verify the patch against your kernel version's advisory or mainline kernel repository. Systems should prioritize this patch if they run x86/EFI with firmware known to generate page faults during runtime calls.

Patch guidance

The fix is a targeted change to the EFI fault handler logic, replacing the condition check from in_interrupt() to !in_task(). This is a minimal change with low regression risk. Apply patches from your Linux distribution's stable kernel updates or backport from mainline. Test on representative hardware with the same firmware revision to confirm the graceful recovery behavior is restored. If your system does not run EFI or has not experienced unexplained panics during firmware calls, the patch still improves correctness and should be applied during regular maintenance windows.

Detection guidance

Monitor system logs for panic messages mentioning 'Fatal exception in interrupt' or kernel stack traces showing efi_crash_gracefully_on_page_fault() followed by die() and panic(). Kernel messages may also show 'EFI' in the context. Systems with this issue will experience hard hangs rather than graceful shutdowns; review boot logs and system uptime patterns for unexplained reboots or freezes correlated with EFI runtime service calls. Firmware vendors' GetTime() or similar runtime service invocations may precede the hang if firmware debug output is enabled.

Why prioritize this

Prioritize patching systems identified as running affected kernel versions on x86/EFI, especially in production environments where availability is critical. The CVSS score reflects the denial-of-service impact and local privilege requirement. While not remotely exploitable, the availability impact is severe—affected systems become unrecoverable without human intervention. Address this in your next maintenance cycle for affected platforms, and sooner for mission-critical infrastructure.

Risk score, explained

The CVSS 3.1 score of 5.5 (MEDIUM) reflects a denial-of-service impact with local access requirements. The vulnerability requires local presence (AV:L), low complexity to trigger (AC:L), and low privilege (PR:L). It results in high availability impact (A:H) but no confidentiality or integrity loss. The score appropriately captures the severity of an unrecoverable system freeze while accounting for the limited attack surface and firmware-dependency.

Frequently asked questions