linux-kernel - Re: [syzbot] [serial?] BUG: soft lockup in debug_check_no_obj

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87iktd51rm.ffs@tglx>
Date: Sun, 27 Oct 2024 10:33:01 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: syzbot <syzbot+a234c2d63e0c171ca10e@...kaller.appspotmail.com>,
 brauner@...nel.org, gregkh@...uxfoundation.org, jack@...e.cz,
 linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-serial@...r.kernel.org, linux-usb@...r.kernel.org,
 syzkaller-bugs@...glegroups.com, viro@...iv.linux.org.uk
Subject: Re: [syzbot] [serial?] BUG: soft lockup in debug_check_no_obj_freed

On Sat, Oct 19 2024 at 08:37, syzbot wrote:

That's not a soft lockup in debug_check_no_obj_freed().

What actually happens is:

>  serial_in drivers/tty/serial/8250/8250.h:137 [inline]
>  serial_lsr_in drivers/tty/serial/8250/8250.h:159 [inline]
>  wait_for_lsr+0xda/0x180 drivers/tty/serial/8250/8250_port.c:2068
>  serial8250_console_fifo_write drivers/tty/serial/8250/8250_port.c:3315 [inline]
>  serial8250_console_write+0xf5a/0x17c0 drivers/tty/serial/8250/8250_port.c:3393
>  console_emit_next_record kernel/printk/printk.c:3092 [inline]
>  console_flush_all+0x800/0xc60 kernel/printk/printk.c:3180
>  __console_flush_and_unlock kernel/printk/printk.c:3239 [inline]
>  console_unlock+0xd9/0x210 kernel/printk/printk.c:3279
>  vprintk_emit+0x424/0x6f0 kernel/printk/printk.c:2407
>  vprintk+0x7f/0xa0 kernel/printk/printk_safe.c:68
>  _printk+0xc8/0x100 kernel/printk/printk.c:2432
>  printk_stack_address arch/x86/kernel/dumpstack.c:72 [inline]
>  show_trace_log_lvl+0x1b7/0x3d0 arch/x86/kernel/dumpstack.c:285
>  sched_show_task kernel/sched/core.c:7589 [inline]
>  sched_show_task+0x3f0/0x5f0 kernel/sched/core.c:7564
>  show_state_filter+0xee/0x320 kernel/sched/core.c:7634
>  k_spec drivers/tty/vt/keyboard.c:667 [inline]
>  k_spec+0xed/0x150 drivers/tty/vt/keyboard.c:656

HID injects a sysrq-t and the task dump takes ages, which is what stalls
RCU.

There is not much what can be done about this as the dump is initiated
from soft interrupt context at interrupt return.

Thanks,

        tglx