CVE-2026-46290

What it actually does

This is a Linux kernel denial-of-service flaw in the x86 EFI runtime-services fault-handling path. A prior FPU/softirq behavior change caused EFI runtime service calls to appear as though they were executing in interrupt context because local bottom halves are disabled during kernel FPU use. When buggy EFI firmware triggers a page fault during an EFI runtime call, such as GetTime(), the kernel’s graceful EFI page-fault recovery path incorrectly bails out. Instead of returning an EFI_ABORTED-style failure and continuing operation, the fault escalates through the fatal exception path and can panic or hard-freeze the system with a message such as "Fatal exception in interrupt".

Why it matters to the business

Affected Linux systems may unexpectedly hang, panic, or become unavailable when interacting with faulty firmware through EFI runtime services. The primary consequence is operational disruption: workloads on the host can stop, clustered services may fail over, and unattended systems may require manual or out-of-band recovery. The available information does not indicate active exploitation, ransomware use, or inclusion in CISA KEV, and the EPSS score is very low, so urgency is driven mainly by exposure to affected kernel versions and platforms with problematic EFI firmware rather than broad internet exploitation.

How an attack unfolds

This vulnerability is not a typical remote code execution issue. Exploitation depends on reaching a kernel code path that invokes EFI runtime services on x86 systems where firmware can fault during the call. The triggering condition may occur naturally through legitimate system operations that query firmware time or other EFI runtime state, or it could be induced by a local actor or workload that repeatedly causes EFI runtime service interaction if the system and kernel configuration expose such interfaces. When the EFI runtime call encounters a firmware page fault, the kernel misclassifies the execution context because the FPU softirq changes set SOFTIRQ_OFFSET in preempt_count. The graceful EFI page-fault handler therefore refuses to recover, the exception path treats the event as occurring in interrupt context, and the machine can panic or freeze instead of safely aborting the EFI call.

How to fix it

Upgrade to a Linux kernel version that includes the x86 EFI fix replacing the incorrect in_interrupt() check with !in_task() in the EFI page-fault handling path. Because no exact fixed package versions were provided, use the relevant distribution or kernel vendor advisory to identify the first fixed kernel release for each maintained branch in use. Prioritize systems that run on x86 hardware with EFI runtime services enabled, have a history of firmware-related kernel warnings, or have previously experienced unexplained panics during EFI calls. As compensating measures, apply available firmware/BIOS/UEFI updates from the hardware vendor, reduce unnecessary use of EFI runtime interfaces where operationally possible, and ensure high-availability or remote recovery mechanisms are in place for systems that cannot be patched immediately.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or build includes the upstream x86/efi fix for graceful fault handling after the FPU softirq change. Check vendor changelogs, kernel source patches, or package metadata for references to replacing in_interrupt() with !in_task() in the EFI crash-gracefully-on-page-fault logic. Validate that systems have actually booted into the fixed kernel, not merely installed it. Review recent kernel logs for EFI runtime-service faults, fatal exception messages, or panic signatures before and after remediation. Where safe and approved, test on representative hardware that previously exhibited EFI runtime-service faults and confirm that firmware page faults are handled gracefully rather than producing a hard freeze.

Typical attack path

1. Identify or gain access to an x86 Linux system running an affected kernel build with EFI runtime services enabled.
2. Determine whether the platform firmware is prone to page faults during EFI runtime service calls, or use normal system interfaces that cause EFI runtime calls to occur.
3. Trigger EFI runtime service activity, such as firmware time or variable-related operations, from local execution or through legitimate system activity that reaches the vulnerable kernel path.
4. Cause or encounter a page fault inside the EFI firmware runtime call.
5. The kernel incorrectly treats the fault as interrupt-context execution and bypasses graceful EFI fault handling.
6. The fault escalates to a fatal exception path, resulting in kernel panic, hard freeze, or unrecoverable host hang.

How to detect it

Look for evidence of prior kernel panics, hard hangs, or crash reports occurring during EFI runtime service activity. Useful sources include kernel ring buffer logs, persistent journald entries, syslog or kern.log, pstore/ramoops records, kdump vmcore metadata, hardware management controller event logs, and hypervisor or cloud host console logs where available. Search for panic strings indicating a fatal exception in interrupt context alongside EFI, page fault, GetTime, SetTime, GetVariable, SetVariable, or runtime-service messages. Because a hard freeze may prevent complete log flushing, absence of logs does not rule out triggering; correlate sudden host unavailability, watchdog resets, BMC power-cycle events, and incomplete kernel logs ending near EFI activity. No reliable network IOC is expected because this is a local/kernel availability condition rather than a network protocol compromise.

• Fatal exception in interrupt
• efi_crash_gracefully_on_page_fault
• EFI runtime
• efi:
• GetTime()
• SetTime()
• GetVariable()
• SetVariable()
• page fault
• BUG: unable to handle page fault
• Oops:
• Kernel panic - not syncing
• Fatal exception
• pstore
• ramoops
• kdump

What your security team should do

• Inventory x86 Linux systems using affected kernel branches and prioritize those with EFI runtime services enabled or known firmware instability.
• Map kernel versions to distribution advisories and schedule upgrades to the first fixed kernel release or later.
• Coordinate with infrastructure teams to update BIOS/UEFI firmware on platforms that have produced EFI runtime-service faults or unexplained kernel panics.
• Monitor kernel logs and crash telemetry for EFI runtime-service fault patterns and "Fatal exception in interrupt" panic messages.
• Ensure critical systems have remote console, watchdog, clustering, or automated recovery procedures because exploitation or triggering may result in a hard hang rather than a clean crash dump.
• Treat this primarily as an availability risk; current metadata shows no KEV listing, no known ransomware use, no named threat actors, and no public exploit maturity.