Public bug reported:
[Impact]
Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, 202511-38088,
02511-38091, 202511-38068, 202511-38069) with 6.17 causes a hardsystem freeze.
The machine becomes unreachable by ping/SSH and requires a hardpower cycle.
Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by making
kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to use
local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in
preempt_count during EFI runtime calls, making in_interrupt() return true in
normal task context. The EFI 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 firmware page faults unhandled. This escalates to die() which also
sees in_interrupt() as true and calls panic("Fatal exception in interrupt"),
freezing the system.
[Fix]
Replace in_interrupt() with !in_task() in efi_crash_gracefully_on_page_fault().
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().
[Test Plan]
1. Boot affected HP machine with the patched 6.17-oem kernel.
2. Run:
$ sudo fwts uefirttime
Without patch: system hard-freezes, requires power cycle.
With patch: fwts completes (pass or fail), system remains responsive.
[Where problems could occur]
The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c).
If !in_task() incorrectly identifies a real interrupt-context fault as task
context, the handler would try to process it as an EFI firmware fault instead
of letting the normal oops path handle it. This could mask real kernel bugs
during interrupt-context EFI faults, though such faults are extremely rare.
Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the
fpregs_lock() call could cause a page fault that gets misidentified. The use
of !in_task() (which incorporates in_serving_softirq()) handles this window
correctly.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Affects: linux-oem-6.17 (Ubuntu)
Importance: Undecided
Status: New
** Affects: linux (Ubuntu Noble)
Importance: Undecided
Status: Invalid
** Affects: linux-oem-6.17 (Ubuntu Noble)
Importance: Undecided
Status: New
** Affects: linux (Ubuntu Resolute)
Importance: Undecided
Status: New
** Affects: linux-oem-6.17 (Ubuntu Resolute)
Importance: Undecided
Status: Invalid
** Description changed:
- [Impact]
- Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089,
202511-38088,
- 202511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem causes a
hard
- system freeze. The machine becomes unreachable by ping/SSH and requires a
hard
- power cycle.
-
- Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by
making
- kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin()
to use
- local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET
in
- preempt_count during EFI runtime calls, making in_interrupt() return true
in
- normal task context. The EFI 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 firmware page faults unhandled. This escalates to die() which
also
- sees in_interrupt() as true and calls panic("Fatal exception in
interrupt"),
- freezing the system.
-
- [Fix]
- Replace in_interrupt() with !in_task() in
efi_crash_gracefully_on_page_fault().
- 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().
-
-
- [Test Plan]
- 1. Boot affected HP machine with the patched 6.17-oem kernel.
- 2. Run:
- $ sudo fwts uefirttime
-
- Without patch: system hard-freezes, requires power cycle.
- With patch: fwts completes (pass or fail), system remains responsive.
-
- [Where problems could occur]
- The change is in the EFI page fault handler
(arch/x86/platform/efi/quirks.c).
-
- If !in_task() incorrectly identifies a real interrupt-context fault as task
- context, the handler would try to process it as an EFI firmware fault
instead
- of letting the normal oops path handle it. This could mask real kernel bugs
- during interrupt-context EFI faults, though such faults are extremely rare.
-
- Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the
- fpregs_lock() call could cause a page fault that gets misidentified. The
use of
- !in_task() (which incorporates in_serving_softirq()) handles this window
- correctly.
-
- [Other Info]
- Upstream commit: 088f65e206087bf903743bd18417261d7a4c9644
- Fixes: d02198550423 ("x86/fpu: Improve crypto performance by making
kernel-mode FPU reliably usable in softirqs") SRU for oem-6.17.
+ [Impact]
+ Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089,
202511-38088,
+ 202511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem causes a
hard
+ system freeze. The machine becomes unreachable by ping/SSH and requires a
hard
+ power cycle.
+
+ Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by
making
+ kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin()
to use
+ local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET
in
+ preempt_count during EFI runtime calls, making in_interrupt() return true
in
+ normal task context. The EFI 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 firmware page faults unhandled. This escalates to die() which
also
+ sees in_interrupt() as true and calls panic("Fatal exception in
interrupt"),
+ freezing the system.
+
+ [Fix]
+ Replace in_interrupt() with !in_task() in
efi_crash_gracefully_on_page_fault().
+ 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().
+
+ [Test Plan]
+ 1. Boot affected HP machine with the patched 6.17-oem kernel.
+ 2. Run:
+ $ sudo fwts uefirttime
+
+ Without patch: system hard-freezes, requires power cycle.
+ With patch: fwts completes (pass or fail), system remains responsive.
+
+ [Where problems could occur]
+ The change is in the EFI page fault handler
(arch/x86/platform/efi/quirks.c).
+
+ If !in_task() incorrectly identifies a real interrupt-context fault as task
+ context, the handler would try to process it as an EFI firmware fault
instead
+ of letting the normal oops path handle it. This could mask real kernel bugs
+ during interrupt-context EFI faults, though such faults are extremely rare.
+
+ Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the
+ fpregs_lock() call could cause a page fault that gets misidentified. The
use of !in_task() (which incorporates in_serving_softirq()) handles this
window
+ correctly.
** Description changed:
[Impact]
- Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089,
202511-38088,
- 202511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem causes a
hard
- system freeze. The machine becomes unreachable by ping/SSH and requires a
hard
- power cycle.
+ Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089,
202511-38088,02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem
causes a hardsystem freeze. The machine becomes unreachable by ping/SSH and
requires a hardpower cycle.
- Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by
making
- kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin()
to use
- local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET
in
- preempt_count during EFI runtime calls, making in_interrupt() return true
in
- normal task context. The EFI 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 firmware page faults unhandled. This escalates to die() which
also
- sees in_interrupt() as true and calls panic("Fatal exception in
interrupt"),
- freezing the system.
+ Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by
making
+ kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to
use
+ local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in
+ preempt_count during EFI runtime calls, making in_interrupt() return true in
+ normal task context. The EFI 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 firmware page faults unhandled. This escalates to die() which
also
+ sees in_interrupt() as true and calls panic("Fatal exception in interrupt"),
+ freezing the system.
- [Fix]
- Replace in_interrupt() with !in_task() in
efi_crash_gracefully_on_page_fault().
- 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().
+ [Fix]
+ Replace in_interrupt() with !in_task() in
efi_crash_gracefully_on_page_fault().
+ 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().
- [Test Plan]
- 1. Boot affected HP machine with the patched 6.17-oem kernel.
- 2. Run:
- $ sudo fwts uefirttime
+ [Test Plan]
+ 1. Boot affected HP machine with the patched 6.17-oem kernel.
+ 2. Run:
+ $ sudo fwts uefirttime
- Without patch: system hard-freezes, requires power cycle.
- With patch: fwts completes (pass or fail), system remains responsive.
+ Without patch: system hard-freezes, requires power cycle.
+ With patch: fwts completes (pass or fail), system remains responsive.
- [Where problems could occur]
- The change is in the EFI page fault handler
(arch/x86/platform/efi/quirks.c).
-
- If !in_task() incorrectly identifies a real interrupt-context fault as task
- context, the handler would try to process it as an EFI firmware fault
instead
- of letting the normal oops path handle it. This could mask real kernel bugs
- during interrupt-context EFI faults, though such faults are extremely rare.
-
- Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the
- fpregs_lock() call could cause a page fault that gets misidentified. The
use of !in_task() (which incorporates in_serving_softirq()) handles this
window
- correctly.
+ [Where problems could occur]
+ The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c).
+ If !in_task() incorrectly identifies a real interrupt-context fault as task
+ context, the handler would try to process it as an EFI firmware fault instead
+ of letting the normal oops path handle it. This could mask real kernel bugs
+ during interrupt-context EFI faults, though such faults are extremely rare.
+ Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the
+ fpregs_lock() call could cause a page fault that gets misidentified. The use
of !in_task() (which incorporates in_serving_softirq()) handles this window
correctly.
** Description changed:
[Impact]
- Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089,
202511-38088,02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem
causes a hardsystem freeze. The machine becomes unreachable by ping/SSH and
requires a hardpower cycle.
+ Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089,
202511-38088,02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem
causes a hardsystem freeze. The machine becomes unreachable by ping/SSH and
requires a
+ hardpower cycle.
Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by
making
kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to
use
local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in
preempt_count during EFI runtime calls, making in_interrupt() return true in
normal task context. The EFI 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 firmware page faults unhandled. This escalates to die() which
also
sees in_interrupt() as true and calls panic("Fatal exception in interrupt"),
freezing the system.
[Fix]
Replace in_interrupt() with !in_task() in
efi_crash_gracefully_on_page_fault().
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().
[Test Plan]
1. Boot affected HP machine with the patched 6.17-oem kernel.
2. Run:
$ sudo fwts uefirttime
Without patch: system hard-freezes, requires power cycle.
With patch: fwts completes (pass or fail), system remains responsive.
[Where problems could occur]
The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c).
If !in_task() incorrectly identifies a real interrupt-context fault as task
context, the handler would try to process it as an EFI firmware fault instead
of letting the normal oops path handle it. This could mask real kernel bugs
during interrupt-context EFI faults, though such faults are extremely rare.
Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the
- fpregs_lock() call could cause a page fault that gets misidentified. The use
of !in_task() (which incorporates in_serving_softirq()) handles this window
correctly.
+ fpregs_lock() call could cause a page fault that gets misidentified. The use
of !in_task() (which incorporates in_serving_softirq()) handles this window
+ correctly.
** Description changed:
[Impact]
- Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089,
202511-38088,02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem
causes a hardsystem freeze. The machine becomes unreachable by ping/SSH and
requires a
+ Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089,
202511-38088,02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem
causes a
+ hardsystem freeze. The machine becomes unreachable by ping/SSH and requires a
hardpower cycle.
Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by
making
kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to
use
local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in
preempt_count during EFI runtime calls, making in_interrupt() return true in
normal task context. The EFI 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 firmware page faults unhandled. This escalates to die() which
also
sees in_interrupt() as true and calls panic("Fatal exception in interrupt"),
freezing the system.
[Fix]
Replace in_interrupt() with !in_task() in
efi_crash_gracefully_on_page_fault().
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().
[Test Plan]
1. Boot affected HP machine with the patched 6.17-oem kernel.
2. Run:
$ sudo fwts uefirttime
Without patch: system hard-freezes, requires power cycle.
With patch: fwts completes (pass or fail), system remains responsive.
[Where problems could occur]
The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c).
If !in_task() incorrectly identifies a real interrupt-context fault as task
context, the handler would try to process it as an EFI firmware fault instead
of letting the normal oops path handle it. This could mask real kernel bugs
during interrupt-context EFI faults, though such faults are extremely rare.
Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the
fpregs_lock() call could cause a page fault that gets misidentified. The use
of !in_task() (which incorporates in_serving_softirq()) handles this window
correctly.
** Description changed:
[Impact]
- Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089,
202511-38088,02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem
causes a
+ Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089,
+ 202511-38088,02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem
causes a
hardsystem freeze. The machine becomes unreachable by ping/SSH and requires a
hardpower cycle.
Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by
making
kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to
use
local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in
preempt_count during EFI runtime calls, making in_interrupt() return true in
normal task context. The EFI 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 firmware page faults unhandled. This escalates to die() which
also
sees in_interrupt() as true and calls panic("Fatal exception in interrupt"),
freezing the system.
[Fix]
Replace in_interrupt() with !in_task() in
efi_crash_gracefully_on_page_fault().
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().
[Test Plan]
1. Boot affected HP machine with the patched 6.17-oem kernel.
2. Run:
$ sudo fwts uefirttime
Without patch: system hard-freezes, requires power cycle.
With patch: fwts completes (pass or fail), system remains responsive.
[Where problems could occur]
The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c).
If !in_task() incorrectly identifies a real interrupt-context fault as task
context, the handler would try to process it as an EFI firmware fault instead
of letting the normal oops path handle it. This could mask real kernel bugs
during interrupt-context EFI faults, though such faults are extremely rare.
Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the
- fpregs_lock() call could cause a page fault that gets misidentified. The use
of !in_task() (which incorporates in_serving_softirq()) handles this window
+ fpregs_lock() call could cause a page fault that gets misidentified. The use
+ of !in_task() (which incorporates in_serving_softirq()) handles this window
correctly.
** Description changed:
[Impact]
- Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089,
+ Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089,
202511-38088,02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem
causes a
hardsystem freeze. The machine becomes unreachable by ping/SSH and requires a
hardpower cycle.
Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by
making
kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to
use
local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in
preempt_count during EFI runtime calls, making in_interrupt() return true in
normal task context. The EFI 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 firmware page faults unhandled. This escalates to die() which
also
sees in_interrupt() as true and calls panic("Fatal exception in interrupt"),
freezing the system.
[Fix]
Replace in_interrupt() with !in_task() in
efi_crash_gracefully_on_page_fault().
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().
[Test Plan]
1. Boot affected HP machine with the patched 6.17-oem kernel.
2. Run:
$ sudo fwts uefirttime
Without patch: system hard-freezes, requires power cycle.
With patch: fwts completes (pass or fail), system remains responsive.
[Where problems could occur]
The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c).
If !in_task() incorrectly identifies a real interrupt-context fault as task
context, the handler would try to process it as an EFI firmware fault instead
of letting the normal oops path handle it. This could mask real kernel bugs
during interrupt-context EFI faults, though such faults are extremely rare.
Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the
- fpregs_lock() call could cause a page fault that gets misidentified. The use
- of !in_task() (which incorporates in_serving_softirq()) handles this window
+ fpregs_lock() call could cause a page fault that gets misidentified. The use
+ of !in_task() (which incorporates in_serving_softirq()) handles this window
correctly.
** Description changed:
[Impact]
- Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089,
- 202511-38088,02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem
causes a
+ Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, 202511-38088,
+ 02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem causes a
hardsystem freeze. The machine becomes unreachable by ping/SSH and requires a
hardpower cycle.
Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by
making
kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to
use
local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in
preempt_count during EFI runtime calls, making in_interrupt() return true in
normal task context. The EFI 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 firmware page faults unhandled. This escalates to die() which
also
sees in_interrupt() as true and calls panic("Fatal exception in interrupt"),
freezing the system.
[Fix]
Replace in_interrupt() with !in_task() in
efi_crash_gracefully_on_page_fault().
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().
[Test Plan]
1. Boot affected HP machine with the patched 6.17-oem kernel.
2. Run:
$ sudo fwts uefirttime
Without patch: system hard-freezes, requires power cycle.
With patch: fwts completes (pass or fail), system remains responsive.
[Where problems could occur]
The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c).
If !in_task() incorrectly identifies a real interrupt-context fault as task
context, the handler would try to process it as an EFI firmware fault instead
of letting the normal oops path handle it. This could mask real kernel bugs
during interrupt-context EFI faults, though such faults are extremely rare.
Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the
fpregs_lock() call could cause a page fault that gets misidentified. The use
- of !in_task() (which incorporates in_serving_softirq()) handles this window
+ of !in_task() (which incorporates in_serving_softirq()) handles this window
correctly.
** Also affects: linux-oem-6.17 (Ubuntu)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Noble)
Importance: Undecided
Status: New
** Also affects: linux-oem-6.17 (Ubuntu Noble)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Resolute)
Importance: Undecided
Status: New
** Also affects: linux-oem-6.17 (Ubuntu Resolute)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Noble)
Status: New => Invalid
** Changed in: linux-oem-6.17 (Ubuntu Resolute)
Status: New => Invalid
** Description changed:
[Impact]
Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, 202511-38088,
- 02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem causes a
- hardsystem freeze. The machine becomes unreachable by ping/SSH and requires a
- hardpower cycle.
+ 02511-38091, 202511-38068, 202511-38069) with 6.17 causes a hardsystem freeze.
+ The machine becomes unreachable by ping/SSH and requires a hardpower cycle.
Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by
making
kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to
use
local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in
preempt_count during EFI runtime calls, making in_interrupt() return true in
normal task context. The EFI 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 firmware page faults unhandled. This escalates to die() which
also
sees in_interrupt() as true and calls panic("Fatal exception in interrupt"),
freezing the system.
[Fix]
Replace in_interrupt() with !in_task() in
efi_crash_gracefully_on_page_fault().
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().
[Test Plan]
1. Boot affected HP machine with the patched 6.17-oem kernel.
2. Run:
$ sudo fwts uefirttime
Without patch: system hard-freezes, requires power cycle.
With patch: fwts completes (pass or fail), system remains responsive.
[Where problems could occur]
The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c).
If !in_task() incorrectly identifies a real interrupt-context fault as task
context, the handler would try to process it as an EFI firmware fault instead
of letting the normal oops path handle it. This could mask real kernel bugs
during interrupt-context EFI faults, though such faults are extremely rare.
Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the
fpregs_lock() call could cause a page fault that gets misidentified. The use
of !in_task() (which incorporates in_serving_softirq()) handles this window
correctly.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2153976
Title:
Fix graceful fault handling after FPU softirq changes causes hard
freeze on EFI runtime calls
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2153976/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
