PT-2026-47362 · Linux · Linux
Published
2026-06-08
·
Updated
2026-06-08
·
CVE-2026-46290
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
x86/efi: Fix graceful fault handling after FPU softirq changes
Since commit d02198550423 ("x86/fpu: Improve crypto performance by
making kernel-mode FPU reliably usable in softirqs"), kernel fpu begin()
calls fpregs lock() which uses local bh disable() instead of the
previous preempt disable(). This sets SOFTIRQ OFFSET in preempt count
during the entire EFI runtime service call, causing in interrupt() to
return true in normal task context.
The graceful page fault handler efi crash gracefully on page fault()
uses in interrupt() to bail out for faults in real interrupt context.
With SOFTIRQ OFFSET now set, the handler always bails out, leaving EFI
firmware page faults unhandled. This escalates to die() which also sees
in interrupt() as true and calls panic("Fatal exception in interrupt"),
resulting in a hard system freeze. On systems with buggy firmware that
triggers page faults during EFI runtime calls (e.g., accessing unmapped
memory in GetTime()), this causes an unrecoverable hang instead of the
expected graceful EFI ABORTED recovery.
Fix by replacing in interrupt() with !in task(). This preserves the
original intent of bailing for interrupts or NMI faults, while no longer
falsely triggering from the FPU code path's local bh disable().
[ardb: Sashiko spotted that using 'in hardirq() || in nmi()' leaves a
window where a softirq may be taken before fpregs lock() is
called, but after efi rts work.efi rts id has been assigned,
and any page faults occurring in that window will then be
misidentified as having been caused by the firmware. Instead,
use !in task(), which incorporates in serving softirq(). ]
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux