CVE-2026-46290

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/efi: Fix graceful fault handling after FPU softirq changes<br /> <br /> Since commit d02198550423 ("x86/fpu: Improve crypto performance by<br /> making kernel-mode FPU reliably usable in softirqs"), kernel_fpu_begin()<br /> calls fpregs_lock() which uses local_bh_disable() instead of the<br /> previous preempt_disable(). This sets SOFTIRQ_OFFSET in preempt_count<br /> during the entire EFI runtime service call, causing in_interrupt() to<br /> return true in normal task context.<br /> <br /> The graceful page fault handler efi_crash_gracefully_on_page_fault()<br /> uses in_interrupt() to bail out for faults in real interrupt context.<br /> With SOFTIRQ_OFFSET now set, the handler always bails out, leaving EFI<br /> firmware page faults unhandled. This escalates to die() which also sees<br /> in_interrupt() as true and calls panic("Fatal exception in interrupt"),<br /> resulting in a hard system freeze. On systems with buggy firmware that<br /> triggers page faults during EFI runtime calls (e.g., accessing unmapped<br /> memory in GetTime()), this causes an unrecoverable hang instead of the<br /> expected graceful EFI_ABORTED recovery.<br /> <br /> Fix by replacing in_interrupt() with !in_task(). This preserves the<br /> original intent of bailing for interrupts or NMI faults, while no longer<br /> falsely triggering from the FPU code path&amp;#39;s local_bh_disable().<br /> <br /> [ardb: Sashiko spotted that using &amp;#39;in_hardirq() || in_nmi()&amp;#39; leaves a<br /> window where a softirq may be taken before fpregs_lock() is<br /> called, but after efi_rts_work.efi_rts_id has been assigned,<br /> and any page faults occurring in that window will then be<br /> misidentified as having been caused by the firmware. Instead,<br /> use !in_task(), which incorporates in_serving_softirq(). ]