kernel/reboot.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
The reboot syscall calls do_exit(0) after kernel_halt() or
kernel_power_off(). Those are expected to stop the machine and not
return. When they do return, the shutdown path has already disabled
interrupts and torn down state, and do_exit() then hits its
WARN_ON(irqs_disabled()).
That is an error path, not a clean exit. Use make_task_dead() instead
of do_exit(0): it is built for this, fixes up the irqs disabled and
preempt state, and bounds repeated failure via oops_limit. This
matches the make_task_dead pattern that exit.c already uses for the
oops path.
Splat from syzbot:
ACPI: PM: Preparing to enter system sleep state S5
kvm: exiting hardware virtualization
reboot: Power down
------------[ cut here ]------------
irqs_disabled()
WARNING: kernel/exit.c:930 at do_exit+0x1cf7/0x2ae0 kernel/exit.c:930, CPU#0: init/6193
Tainted: [L]=SOFTLOCKUP
Call Trace:
<TASK>
__do_sys_reboot+0x36e/0x400 kernel/reboot.c:784
do_syscall_64+0x115/0x840 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
Fixes: 001c28e57187 ("exit: Detect and fix irq disabled state in oops")
Reported-by: syzbot+8fdf0d8e10bdde1c2e88@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=8fdf0d8e10bdde1c2e88
Cc: stable@vger.kernel.org
Signed-off-by: Bradley Morgan <include@grrlz.net>
---
kernel/reboot.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
Changes since v1: v1 enabled IRQs and kept do_exit, fixing the
symptom. Eric Biederman pointed out the real fix is to treat the
returned halt or power off as the error path it is, and call
make_task_dead instead.
diff --git a/kernel/reboot.c b/kernel/reboot.c
index bed6967bfa96..c10ac6a0200d 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -14,6 +14,7 @@
#include <linux/kmod.h>
#include <linux/kmsg_dump.h>
#include <linux/reboot.h>
+#include <linux/sched/task.h>
#include <linux/suspend.h>
#include <linux/syscalls.h>
#include <linux/syscore_ops.h>
@@ -777,11 +778,13 @@ SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,
case LINUX_REBOOT_CMD_HALT:
kernel_halt();
- do_exit(0);
+ /* machine_halt() was expected to not return. */
+ make_task_dead(SIGKILL);
case LINUX_REBOOT_CMD_POWER_OFF:
kernel_power_off();
- do_exit(0);
+ /* machine_power_off() was expected to not return. */
+ make_task_dead(SIGKILL);
break;
case LINUX_REBOOT_CMD_RESTART2:
--
2.53.0
On Mon, 13 Jul 2026 06:23:32 +0000 Bradley Morgan <include@grrlz.net> wrote: > The reboot syscall calls do_exit(0) after kernel_halt() or > kernel_power_off(). Those are expected to stop the machine and not > return. When they do return, the shutdown path has already disabled > interrupts and torn down state, and do_exit() then hits its > WARN_ON(irqs_disabled()). Well... why are they returning? Is it both kernel_halt() and kernel_power_off()? The report seems to indicate that kernel_power_off() is returning. So is there a flaw in x86 machine_power_off() which we should be addressing? > That is an error path, not a clean exit. Use make_task_dead() instead > of do_exit(0): it is built for this, fixes up the irqs disabled and > preempt state, and bounds repeated failure via oops_limit. This > matches the make_task_dead pattern that exit.c already uses for the > oops path. And make_tsk_dead() is __noreturn.
On July 14, 2026 2:10:01 AM GMT+01:00, Andrew Morton <akpm@linux-foundation.org> wrote: >On Mon, 13 Jul 2026 06:23:32 +0000 Bradley Morgan <include@grrlz.net> >wrote: > >> The reboot syscall calls do_exit(0) after kernel_halt() or >> kernel_power_off(). Those are expected to stop the machine and not >> return. When they do return, the shutdown path has already disabled >> interrupts and torn down state, and do_exit() then hits its >> WARN_ON(irqs_disabled()). > >Well... why are they returning? Is it both kernel_halt() and >kernel_power_off()? The report seems to indicate that >kernel_power_off() is returning. native_machine_power_off() has no __noreturn backstop. (Only for kernel_power_off, kernel_halt() is theoretically safe, ends in stop_this_cpu) >So is there a flaw in x86 machine_power_off() which we should be >addressing? Well, yes, but it's really not that simple Andrew... I did a quick dig at the other arches code and guess what? x86, arm, arm64, (loongarch, riscv) power_off can all return, (BUG!) So just doing a fix arch specific isn't really right (unless we want a 3-5 patch series, which just adds more complication) >> That is an error path, not a clean exit. Use make_task_dead() instead >> of do_exit(0): it is built for this, fixes up the irqs disabled and >> preempt state, and bounds repeated failure via oops_limit. This >> matches the make_task_dead pattern that exit.c already uses for the >> oops path. > >And make_tsk_dead() is __noreturn. Nice catch! let's just remove break;, it's dead code > > Thanks!
On July 14, 2026 4:48:09 PM GMT+01:00, Bradley Morgan <include@grrlz.net> wrote: >On July 14, 2026 2:10:01 AM GMT+01:00, Andrew Morton ><akpm@linux-foundation.org> wrote: >>On Mon, 13 Jul 2026 06:23:32 +0000 Bradley Morgan <include@grrlz.net> >>wrote: >> >>> The reboot syscall calls do_exit(0) after kernel_halt() or >>> kernel_power_off(). Those are expected to stop the machine and not >>> return. When they do return, the shutdown path has already disabled >>> interrupts and torn down state, and do_exit() then hits its >>> WARN_ON(irqs_disabled()). >> >>Well... why are they returning? Is it both kernel_halt() and >>kernel_power_off()? The report seems to indicate that >>kernel_power_off() is returning. > >native_machine_power_off() has no __noreturn backstop. > >(Only for kernel_power_off, kernel_halt() is theoretically safe, ends in >stop_this_cpu) > >>So is there a flaw in x86 machine_power_off() which we should be >>addressing? > >Well, yes, but it's really not that simple Andrew... > >I did a quick dig at the other arches code and guess what? > >x86, arm, arm64, (loongarch, riscv) power_off can all return, >(BUG!) > > >So just doing a fix arch specific isn't really right (unless we want a >3-5 patch series, which just adds more complication) > >>> That is an error path, not a clean exit. Use make_task_dead() instead >>> of do_exit(0): it is built for this, fixes up the irqs disabled and >>> preempt state, and bounds repeated failure via oops_limit. This >>> matches the make_task_dead pattern that exit.c already uses for the >>> oops path. >> >>And make_tsk_dead() is __noreturn. > >Nice catch! let's just remove break;, it's dead code > >> >> > >Thanks! Andrew? What do you think of this? (Sorry for the ping) Thanks!
© 2016 - 2026 Red Hat, Inc.