linux-kernel - Re: [syzbot] [serial?] possible deadlock in console_lock_spinning

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: <d9c11abd-03a6-466f-bfdc-ee9a57ad881c@I-love.SAKURA.ne.jp>
Date: Mon, 10 Jun 2024 09:46:44 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Hillf Danton <hdanton@...a.com>,
        syzbot <syzbot+0f558b549182d2711c75@...kaller.appspotmail.com>
Cc: gregkh@...uxfoundation.org, jirislaby@...nel.org,
        Boqun Feng <boqun.feng@...il.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [serial?] possible deadlock in
 console_lock_spinning_enable (4)

On 2024/06/10 9:19, Hillf Danton wrote:
> On Sun, 09 Jun 2024 08:24:24 -0700
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit:    8867bbd4a056 mm: arm64: Fix the out-of-bounds issue in con..
>> git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
>> console output: https://syzkaller.appspot.com/x/log.txt?x=14d199ce980000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=3b4350cf56c61c80
>> dashboard link: https://syzkaller.appspot.com/bug?extid=0f558b549182d2711c75
>> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
>> userspace arch: arm64
>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11493bc2980000
>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=146cff16980000

#syz dup: possible deadlock in console_flush_all (2)

>> -> #0 (console_owner){....}-{0:0}:
>>        check_prev_add kernel/locking/lockdep.c:3134 [inline]
>>        check_prevs_add kernel/locking/lockdep.c:3253 [inline]
>>        validate_chain kernel/locking/lockdep.c:3869 [inline]
>>        __lock_acquire+0x3384/0x763c kernel/locking/lockdep.c:5137
>>        lock_acquire+0x248/0x73c kernel/locking/lockdep.c:5754
>>        console_lock_spinning_enable+0xb4/0xec kernel/printk/printk.c:1870
>>        console_emit_next_record kernel/printk/printk.c:2922 [inline]
>>        console_flush_all+0x58c/0xb74 kernel/printk/printk.c:2994
>>        console_unlock+0xec/0x3d4 kernel/printk/printk.c:3063
>>        vprintk_emit+0x1ec/0x350 kernel/printk/printk.c:2345
>>        vprintk_default+0xa0/0xe4 kernel/printk/printk.c:2360
>>        vprintk+0x200/0x2d4 kernel/printk/printk_safe.c:45
>>        _printk+0xdc/0x128 kernel/printk/printk.c:2370
>>        __report_bug lib/bug.c:195 [inline]
>>        report_bug+0x3b8/0x5b0 lib/bug.c:219
>>        bug_handler+0x50/0x1fc arch/arm64/kernel/traps.c:978
>>        call_break_hook arch/arm64/kernel/debug-monitors.c:321 [inline]
>>        brk_handler+0x17c/0x2e0 arch/arm64/kernel/debug-monitors.c:328
>>        do_debug_exception+0x1e4/0x398 arch/arm64/mm/fault.c:909
>>        el1_dbg+0x64/0x80 arch/arm64/kernel/entry-common.c:472
>>        el1h_64_sync_handler+0x40/0xac arch/arm64/kernel/entry-common.c:512
>>        el1h_64_sync+0x64/0x68 arch/arm64/kernel/entry.S:593
>>        spin_unlock_irqrestore include/linux/spinlock.h:406 [inline]
>>        uart_port_unlock_irqrestore include/linux/serial_core.h:669 [inline]
> 
> in include/linux/spinlock_api_smp.h
> static inline void __raw_spin_unlock_irqrestore(raw_spinlock_t *lock, unsigned long flags)
> {
> 	spin_release(&lock->dep_map, _RET_IP_);
> 	do_raw_spin_unlock(lock);
> 	local_irq_restore(flags);
> 	preempt_enable();
> }
> 
> Because spin_release() goes before restoring local irq, the port_lock
> should have been ruled out of lockdep that triggered this report. But
> it was delivered to lore.

This report is just an yet another instance of trying to printk()
while holding port_lock. Like I mentioned at
https://lkml.kernel.org/r/acfef6bc-08eb-4ab6-b6d4-9ad03c714517@kernel.org ,
we might want to guard uart_port_lock'ed section using
printk_deferred_enter()/printk_deferred_exit().