Re: [PATCH v2] tty: ldisc: fix deadlock between ldisc_sem and rtnl_mutex

[email protected] Wed, 22 Jul 2026 08:51:58 +0000
Newsgroups org.kernel.vger.linux-can
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] A Time-of-Check to Time-of-Use (TOCTOU) race condition in `tty_ldisc_ref_wait` can cause spurious EOF or -EIO errors for concurrent readers.

Pre-existing issues:
- [High] The circular lock dependency (ldisc_sem -> rtnl_mutex) is not fully resolved in error fallback, hangup, and teardown paths.
--

--- Patch [1]: [PATCH v2] tty: ldisc: fix deadlock between ldisc_sem and rtnl_mutex ---
commit aa2b45f5a2e0cd2e80f19ce89583432e4e6eb9e4
Author: Yun Zhou <[email protected]>

tty: ldisc: fix deadlock between ldisc_sem and rtnl_mutex

syzbot reported a circular lock dependency involving tty ldisc_sem and
the networking rtnl_mutex. Fix by moving the .open() call outside the
ldisc_sem write lock.

Closes: https://syzkaller.appspot.com/bug?extid=de610eeef174bd59a8a3

> diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
> index 27fe8236f6623..bd94a1f13c44c 100644
> --- a/drivers/tty/tty_ldisc.c
> +++ b/drivers/tty/tty_ldisc.c
> @@ -242,8 +242,20 @@ struct tty_ldisc *tty_ldisc_ref_wait(struct tty_struct *tty)
>  
>  	ldsem_down_read(&tty->ldisc_sem, MAX_SCHEDULE_TIMEOUT);
>  	ld = tty->ldisc;
> -	if (!ld)
> +	if (!ld) {
>  		ldsem_up_read(&tty->ldisc_sem);
> +
> +		/* ldisc may be NULL during a discipline switch; wait and retry */
> +		if (!test_bit(TTY_HUPPED, &tty->flags)) {

[Severity: Medium]
Could this if statement lead to a Time-of-Check to Time-of-Use (TOCTOU)
race condition returning spurious EOF or -EIO to concurrent readers?

If a reader thread waits here for a discipline switch to finish, the writer
finishes, wakes up the reader, and drops tty_lock. Before the reader can
acquire ldisc_sem(read) again, a third thread could initiate another line
discipline switch, acquiring tty_lock and setting tty->ldisc = NULL.

Since this uses an if statement instead of a while loop, wouldn't the reader
see NULL again and incorrectly return NULL without retrying?

> +			wait_event(tty->read_wait,
> +				   READ_ONCE(tty->ldisc) != NULL ||
> +				   test_bit(TTY_HUPPED, &tty->flags));
> +			ldsem_down_read(&tty->ldisc_sem, MAX_SCHEDULE_TIMEOUT);
> +			ld = tty->ldisc;
> +			if (!ld)
> +				ldsem_up_read(&tty->ldisc_sem);
> +		}
> +	}
>  	return ld;
>  }

[ ... ]

> @@ -556,15 +568,28 @@ int tty_set_ldisc(struct tty_struct *tty, int disc)
>  	/* Shutdown the old discipline. */
>  	tty_ldisc_close(tty, old_ldisc);

[Severity: High]
This is a pre-existing issue, but doesn't the circular lock dependency
still exist in the teardown, hangup, and error fallback paths?

Switching away from a network line discipline (like slcan or slip) calls
.close() here while ldisc_sem is held for write. The .close() callback calls
unregister_netdev(), acquiring rtnl_mutex.

Similarly, if opening a new discipline fails, the fallback tty_ldisc_failto()
calls .open() under ldisc_sem, recreating the exact same deadlock. The same
happens in tty_ldisc_reinit().

> -	/* Now set up the new line discipline. */
> -	tty->ldisc = new_ldisc;
> +	/* Clear tty->ldisc so concurrent readers back off during transition */
> +	tty->ldisc = NULL;

-- 
Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1