CVE-2026-46290: x86/efi: Fix graceful fault handling after FPU softirq changes

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"), kernelfpubegin() calls fpregslock() which uses localbhdisable() instead of the previous preemptdisable(). This sets SOFTIRQOFFSET in preemptcount during the entire EFI runtime service call, causing ininterrupt() to return true in normal task context.

The graceful page fault handler eficrashgracefullyonpagefault() uses ininterrupt() to bail out for faults in real interrupt context. With SOFTIRQOFFSET now set, the handler always bails out, leaving EFI firmware page faults unhandled. This escalates to die() which also sees ininterrupt() 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 EFIABORTED recovery.

Fix by replacing ininterrupt() with !intask(). This preserves the original intent of bailing for interrupts or NMI faults, while no longer falsely triggering from the FPU code path's localbhdisable().

[ardb: Sashiko spotted that using 'inhardirq() || innmi()' leaves a window where a softirq may be taken before fpregslock() is called, but after efirtswork.efirtsid has been assigned, and any page faults occurring in that window will then be misidentified as having been caused by the firmware. Instead, use !intask(), which incorporates inservingsoftirq(). ]