From: sashiko-bot@kernel.org
To: "Yun Zhou" <yun.zhou@windriver.com>
Cc: "Oliver Hartkopp" <socketcan@hartkopp.net>,
"Oleksij Rempel" <o.rempel@pengutronix.de>,
"Marc Kleine-Budde" <mkl@pengutronix.de>,
"Vincent Mailhol" <mailhol@kernel.org>,
linux-can@vger.kernel.org
Subject: Re: [PATCH] tty: ldisc: fix deadlock between ldisc_sem and rtnl_mutex
Date: Fri, 17 Jul 2026 06:48:05 +0000 [thread overview]
Message-ID: <20260717064805.D025B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260716064719.1401892-1-yun.zhou@windriver.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] Concurrent read/write/poll system calls spuriously return EOF or EIO during line discipline transitions, breaking UAPI.
Pre-existing issues:
- [High] The circular lock dependency between ldisc_sem and rtnl_mutex is not fully resolved, remaining on the error handling and hangup paths.
--
--- Patch [1]: [PATCH] tty: ldisc: fix deadlock between ldisc_sem and rtnl_mutex ---
commit bb627a1c685e7cab3f8500d0d87506f028ebe9fe
Author: Yun Zhou <yun.zhou@windriver.com>
tty: ldisc: fix deadlock between ldisc_sem and rtnl_mutex
This commit aims to fix a circular lock dependency between the tty ldisc_sem
and the networking rtnl_mutex. It does this by modifying tty_set_ldisc() to
call the line discipline open() callback outside of 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..248a6995cc53a 100644
> --- a/drivers/tty/tty_ldisc.c
> +++ b/drivers/tty/tty_ldisc.c
> @@ -556,15 +556,28 @@ int tty_set_ldisc(struct tty_struct *tty, int disc)
> /* Shutdown the old discipline. */
> tty_ldisc_close(tty, old_ldisc);
>
> - /* Now set up the new line discipline. */
> - tty->ldisc = new_ldisc;
> + /* Clear tty->ldisc so concurrent readers back off during transition */
> + tty->ldisc = NULL;
> tty_set_termios_ldisc(tty, disc);
> + tty_ldisc_unlock(tty);
[Severity: High]
Does unlocking the semaphore while the ldisc pointer is NULL introduce a UAPI
break for concurrent operations?
If a concurrent process calls read(), write(), or poll() during this unlocked
window, it can enter tty_ldisc_ref_wait() in drivers/tty/tty_io.c. Because the
semaphore was unlocked here, tty_ldisc_ref_wait() will successfully acquire
the read lock but observe tty->ldisc as NULL.
This causes the reader to immediately return EOF or -EIO, potentially
aborting userspace applications unexpectedly during a line discipline
transition.
> +
> + /*
> + * Open the new discipline outside ldisc_sem. The ldisc .open()
> + * may acquire locks (e.g., rtnl_mutex) that would create circular
> + * dependencies if taken under ldisc_sem. tty_lock is still held,
> + * preventing concurrent ldisc changes and hangup.
> + */
> retval = tty_ldisc_open(tty, new_ldisc);
> +
> + tty_ldisc_lock(tty, MAX_SCHEDULE_TIMEOUT);
> +
> if (retval < 0) {
> /* Back to the old one or N_TTY if we can't */
> tty_ldisc_put(new_ldisc);
> tty_ldisc_restore(tty, old_ldisc);
[Severity: High]
This is a pre-existing issue, but does this fully resolve the circular lock
dependency?
If tty_ldisc_open() fails above, the error path calls tty_ldisc_restore(),
which eventually calls tty_ldisc_failto(). Inside tty_ldisc_failto(),
tty_ldisc_open() is called while the ldisc_sem write lock is held.
Similarly, during hangup processing, tty_ldisc_reinit() calls tty_ldisc_open()
while holding the ldisc_sem write lock.
If the restored or reinitialized discipline acquires rtnl_mutex on these paths,
it appears the lock inversion and potential deadlock would still occur.
> + } else {
> + /* Success - install new ldisc */
> + tty->ldisc = new_ldisc;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260716064719.1401892-1-yun.zhou@windriver.com?part=1
prev parent reply other threads:[~2026-07-17 6:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 6:47 [PATCH] tty: ldisc: fix deadlock between ldisc_sem and rtnl_mutex Yun Zhou
2026-07-16 7:57 ` Greg KH
2026-07-17 3:03 ` Zhou, Yun
2026-07-16 7:59 ` Jagielski, Jedrzej
2026-07-17 3:42 ` Zhou, Yun
2026-07-17 6:50 ` Oliver Hartkopp
2026-07-17 7:02 ` Jagielski, Jedrzej
2026-07-17 6:48 ` 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=20260717064805.D025B1F000E9@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.