Linux CAN drivers development
 help / color / mirror / Atom feed
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

      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