linux-kernel - Re: possible deadlock in tty

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>] [day] [month] [year] [list]
Message-ID: <54a3b906-790e-fd5d-6f6f-a6a9a711d08f@suse.com>
Date:   Fri, 28 Feb 2020 11:04:23 +0100
From:   Jiri Slaby <jslaby@...e.com>
To:     Hillf Danton <hdanton@...a.com>,
        syzbot <syzbot+26183d9746e62da329b8@...kaller.appspotmail.com>
Cc:     gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: possible deadlock in tty_unthrottle

On 27. 02. 20, 12:36, Hillf Danton wrote:
> 
> On Thu, 27 Feb 2020 00:39:12 -0800
>> syzbot found the following crash on:
>>
>> HEAD commit:    f8788d86 Linux 5.6-rc3
>> git tree:       upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1102d22de00000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=5d2e033af114153f
>> dashboard link: https://syzkaller.appspot.com/bug?extid=26183d9746e62da329b8
>> compiler:       clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
>>
>> Unfortunately, I don't have any reproducer for this crash yet.
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+26183d9746e62da329b8@...kaller.appspotmail.com
>>
>> ======================================================
>> WARNING: possible circular locking dependency detected
>> 5.6.0-rc3-syzkaller #0 Not tainted
>> ------------------------------------------------------
>> syz-executor.4/20336 is trying to acquire lock:
>> ffff8880a2e952a0 (&tty->termios_rwsem){++++}, at: tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136
>>
>> but task is already holding lock:
>> ffffffff89462e70 (sel_lock){+.+.}, at: paste_selection+0x118/0x470 drivers/tty/vt/selection.c:374
>>
>> which lock already depends on the new lock.

>> the existing dependency chain (in reverse order) is:
>>
>> -> #2 (sel_lock){+.+.}:
>>        mutex_lock_nested+0x1b/0x30 kernel/locking/mutex.c:1118
>>        set_selection_kernel+0x3b8/0x18a0 drivers/tty/vt/selection.c:217
>>        set_selection_user+0x63/0x80 drivers/tty/vt/selection.c:181
>>        tioclinux+0x103/0x530 drivers/tty/vt/vt.c:3050
>>        vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364

This is ioctl(TIOCL_SETSEL).
Locks held on the path: console_lock -> sel_lock

>> -> #1 (console_lock){+.+.}:
>>        console_lock+0x46/0x70 kernel/printk/printk.c:2289
>>        con_flush_chars+0x50/0x650 drivers/tty/vt/vt.c:3223
>>        n_tty_write+0xeae/0x1200 drivers/tty/n_tty.c:2350
>>        do_tty_write drivers/tty/tty_io.c:962 [inline]
>>        tty_write+0x5a1/0x950 drivers/tty/tty_io.c:1046

This is write().
Locks held on the path: termios_rwsem -> console_lock

>> -> #0 (&tty->termios_rwsem){++++}:
>>        down_write+0x57/0x140 kernel/locking/rwsem.c:1534
>>        tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136
>>        mkiss_receive_buf+0x12aa/0x1340 drivers/net/hamradio/mkiss.c:902
>>        tty_ldisc_receive_buf+0x12f/0x170 drivers/tty/tty_buffer.c:465
>>        paste_selection+0x346/0x470 drivers/tty/vt/selection.c:389
>>        tioclinux+0x121/0x530 drivers/tty/vt/vt.c:3055
>>        vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364

This is ioctl(TIOCL_PASTESEL).
Locks held on the path: sel_lock -> termios_rwsem

>> other info that might help us debug this:
>>
>> Chain exists of:
>>   &tty->termios_rwsem --> console_lock --> sel_lock

Clearly. We have from the above:
console_lock -> sel_lock
sel_lock -> termios_rwsem
termios_rwsem -> console_lock

> The sel_lock was introduced in
> 	07e6124a1a46 ("vt: selection, close sel_buffer race")
> 
> and with it in position can we cut one lock for setting selection?
> 
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -3015,8 +3015,6 @@ static struct console vt_console_driver
>   *
>   * There are some functions which can sleep for arbitrary periods
>   * (paste_selection) but we don't need the lock there anyway.
> - *
> - * set_selection_user has locking, and definitely needs it
>   */
>  
>  int tioclinux(struct tty_struct *tty, unsigned long arg)
> @@ -3035,10 +3033,8 @@ int tioclinux(struct tty_struct *tty, un
>  	switch (type)
>  	{
>  		case TIOCL_SETSEL:
> -			console_lock();
>  			ret = set_selection_user((struct tiocl_selection
>  						 __user *)(p+1), tty);
> -			console_unlock();

This won't fly. First, set_selection_user is not the only caller of
set_selection_kernel with console lock held. Second, we really have to
hold the console lock. The first thing to literally yell would be
poke_blanked_console in set_selection_user :).

But let's switch the order of the locks. Let console lock nest under
sel_lock and not vice versa. I will prepare a patch shortly.

thanks,
-- 
js
suse labs