From: sashiko-bot@kernel.org
To: "Yun Zhou" <yun.zhou@windriver.com>
Cc: "Oliver Hartkopp" <socketcan@hartkopp.net>,
"Oleksij Rempel" <o.rempel@pengutronix.de>,
linux-can@vger.kernel.org,
"Marc Kleine-Budde" <mkl@pengutronix.de>,
"Vincent Mailhol" <mailhol@kernel.org>
Subject: Re: [PATCH v2] tty: ldisc: fix deadlock between ldisc_sem and rtnl_mutex
Date: Wed, 22 Jul 2026 08:51:58 +0000 [thread overview]
Message-ID: <20260722085200.38F681F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260721085035.2485657-1-yun.zhou@windriver.com>
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 <yun.zhou@windriver.com>
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/20260721085035.2485657-1-yun.zhou@windriver.com?part=1
prev parent reply other threads:[~2026-07-22 8:52 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-21 8:50 [PATCH v2] tty: ldisc: fix deadlock between ldisc_sem and rtnl_mutex Yun Zhou
2026-07-22 8:51 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260722085200.38F681F00A3D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-can@vger.kernel.org \
--cc=mailhol@kernel.org \
--cc=mkl@pengutronix.de \
--cc=o.rempel@pengutronix.de \
--cc=sashiko-reviews@lists.linux.dev \
--cc=socketcan@hartkopp.net \
--cc=yun.zhou@windriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox