Linux Serial subsystem development
 help / color / mirror / Atom feed
* [PATCH tty] tty: n_gsm: fix use-after-free in gsm_queue vs gsm_cleanup_mux race
@ 2026-05-26 10:29 Zhenghang Xiao
  2026-05-27  8:16 ` Greg KH
  0 siblings, 1 reply; 4+ messages in thread
From: Zhenghang Xiao @ 2026-05-26 10:29 UTC (permalink / raw)
  To: gregkh, jirislaby; +Cc: linux-serial, Zhenghang Xiao

gsm_queue() reads gsm->dlci[address] into a local pointer in the
flush_to_ldisc workqueue without any lock. Concurrently,
gsm_cleanup_mux() (triggered by GSMIOC_SETCONF ioctl) frees DLCIs under
gsm->mutex — which the receive path never holds. The cached pointer in
gsm_queue() becomes dangling, and the subsequent dlci->data() call
dereferences freed memory.

Fix this by:
1. Checking gsm->dead at the start of gsmld_receive_buf() to reject
   frame processing after cleanup has begun.
2. Moving tty_ldisc_flush() before the DLCI release loop in
   gsm_cleanup_mux(). tty_ldisc_flush() acquires the tty buffer lock
   (buf->lock), which serializes against any in-flight flush_to_ldisc
   work. After it returns, in-flight receive processing has completed,
   and subsequent calls see gsm->dead and return early.

Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
Signed-off-by: Zhenghang Xiao <kipreyyy@gmail.com>
---
 drivers/tty/n_gsm.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index c13e050de83b..8322fffbaeba 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -3156,12 +3156,18 @@ static void gsm_cleanup_mux(struct gsm_mux *gsm, bool disc)
 		gsm_unregister_devices(gsm_tty_driver, gsm->num);
 		gsm->has_devices = false;
 	}
+	/*
+	 * Flush the ldisc before releasing DLCIs. tty_ldisc_flush() waits
+	 * for any in-flight flush_to_ldisc work to complete via buf->lock,
+	 * and the gsm->dead check added to gsmld_receive_buf() rejects any
+	 * future receive processing. This ensures gsm_queue() cannot access
+	 * a DLCI being freed.
+	 */
+	tty_ldisc_flush(gsm->tty);
 	for (i = NUM_DLCI - 1; i >= 0; i--)
 		if (gsm->dlci[i])
 			gsm_dlci_release(gsm->dlci[i]);
 	mutex_unlock(&gsm->mutex);
-	/* Now wipe the queues */
-	tty_ldisc_flush(gsm->tty);
 
 	guard(spinlock_irqsave)(&gsm->tx_lock);
 	list_for_each_entry_safe(txq, ntxq, &gsm->tx_ctrl_list, list)
@@ -3604,6 +3610,9 @@ static void gsmld_receive_buf(struct tty_struct *tty, const u8 *cp,
 	struct gsm_mux *gsm = tty->disc_data;
 	u8 flags = TTY_NORMAL;
 
+	if (gsm->dead)
+		return;
+
 	if (debug & DBG_DATA)
 		gsm_hex_dump_bytes(__func__, cp, count);
 
-- 
2.50.1 (Apple Git-155)


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH tty] tty: n_gsm: fix use-after-free in gsm_queue vs gsm_cleanup_mux race
  2026-05-26 10:29 [PATCH tty] tty: n_gsm: fix use-after-free in gsm_queue vs gsm_cleanup_mux race Zhenghang Xiao
@ 2026-05-27  8:16 ` Greg KH
  2026-05-29  6:28   ` Zhenghang Xiao
  0 siblings, 1 reply; 4+ messages in thread
From: Greg KH @ 2026-05-27  8:16 UTC (permalink / raw)
  To: Zhenghang Xiao; +Cc: jirislaby, linux-serial

On Tue, May 26, 2026 at 06:29:24PM +0800, Zhenghang Xiao wrote:
> gsm_queue() reads gsm->dlci[address] into a local pointer in the
> flush_to_ldisc workqueue without any lock. Concurrently,
> gsm_cleanup_mux() (triggered by GSMIOC_SETCONF ioctl) frees DLCIs under
> gsm->mutex — which the receive path never holds. The cached pointer in
> gsm_queue() becomes dangling, and the subsequent dlci->data() call
> dereferences freed memory.
> 
> Fix this by:
> 1. Checking gsm->dead at the start of gsmld_receive_buf() to reject
>    frame processing after cleanup has begun.
> 2. Moving tty_ldisc_flush() before the DLCI release loop in
>    gsm_cleanup_mux(). tty_ldisc_flush() acquires the tty buffer lock
>    (buf->lock), which serializes against any in-flight flush_to_ldisc
>    work. After it returns, in-flight receive processing has completed,
>    and subsequent calls see gsm->dead and return early.
> 
> Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
> Signed-off-by: Zhenghang Xiao <kipreyyy@gmail.com>
> ---
>  drivers/tty/n_gsm.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)

Cool, how did you test this?


> 
> diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
> index c13e050de83b..8322fffbaeba 100644
> --- a/drivers/tty/n_gsm.c
> +++ b/drivers/tty/n_gsm.c
> @@ -3156,12 +3156,18 @@ static void gsm_cleanup_mux(struct gsm_mux *gsm, bool disc)
>  		gsm_unregister_devices(gsm_tty_driver, gsm->num);
>  		gsm->has_devices = false;
>  	}
> +	/*
> +	 * Flush the ldisc before releasing DLCIs. tty_ldisc_flush() waits
> +	 * for any in-flight flush_to_ldisc work to complete via buf->lock,
> +	 * and the gsm->dead check added to gsmld_receive_buf() rejects any
> +	 * future receive processing. This ensures gsm_queue() cannot access
> +	 * a DLCI being freed.
> +	 */
> +	tty_ldisc_flush(gsm->tty);
>  	for (i = NUM_DLCI - 1; i >= 0; i--)
>  		if (gsm->dlci[i])
>  			gsm_dlci_release(gsm->dlci[i]);
>  	mutex_unlock(&gsm->mutex);
> -	/* Now wipe the queues */
> -	tty_ldisc_flush(gsm->tty);
>  
>  	guard(spinlock_irqsave)(&gsm->tx_lock);
>  	list_for_each_entry_safe(txq, ntxq, &gsm->tx_ctrl_list, list)
> @@ -3604,6 +3610,9 @@ static void gsmld_receive_buf(struct tty_struct *tty, const u8 *cp,
>  	struct gsm_mux *gsm = tty->disc_data;
>  	u8 flags = TTY_NORMAL;
>  
> +	if (gsm->dead)
> +		return;
> +

What prevents dead from changing right after you test this?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH tty] tty: n_gsm: fix use-after-free in gsm_queue vs gsm_cleanup_mux race
  2026-05-27  8:16 ` Greg KH
@ 2026-05-29  6:28   ` Zhenghang Xiao
  2026-05-30  5:19     ` Greg KH
  0 siblings, 1 reply; 4+ messages in thread
From: Zhenghang Xiao @ 2026-05-29  6:28 UTC (permalink / raw)
  To: Greg KH; +Cc: jirislaby, linux-serial

Resending this email as plain text, since the previous reply was
rejected by the mailing list for containing an HTML part.
-------------------
Thanks for your reply!

> How to test
I built two identical arm64 kernels (v7.1.0-rc4), differing only by
this patch. Both kernel carry a msleep(20) instrumentation in
gsm_queue() to widen the race window. Then run PoC and the patched
kernel do not report kASAN again.

> What prevents dead from changing
Nothing prevents it and it doesn't need to. tty_ldisc_flush() is the
sync mechanism not dead check.
If gsmld_receive_buf() is already past the check, it's running under
buf->lock. The patch moves tty_ldisc_flush() before DLCI release. And
tty_buffer_flush() acquires the same buf->lock, so it blocks until the
in-flight receive completes. DLCIs are freed only after that.

The dead check handles the other direction, any receive that starts
after the flush sees dead == true and returns early. But I'm not sure
if silent drop here is fine or not.

Thanks!
Zhenghang


Greg KH <gregkh@linuxfoundation.org> 于2026年5月27日周三 16:17写道:
>
> On Tue, May 26, 2026 at 06:29:24PM +0800, Zhenghang Xiao wrote:
> > gsm_queue() reads gsm->dlci[address] into a local pointer in the
> > flush_to_ldisc workqueue without any lock. Concurrently,
> > gsm_cleanup_mux() (triggered by GSMIOC_SETCONF ioctl) frees DLCIs under
> > gsm->mutex — which the receive path never holds. The cached pointer in
> > gsm_queue() becomes dangling, and the subsequent dlci->data() call
> > dereferences freed memory.
> >
> > Fix this by:
> > 1. Checking gsm->dead at the start of gsmld_receive_buf() to reject
> >    frame processing after cleanup has begun.
> > 2. Moving tty_ldisc_flush() before the DLCI release loop in
> >    gsm_cleanup_mux(). tty_ldisc_flush() acquires the tty buffer lock
> >    (buf->lock), which serializes against any in-flight flush_to_ldisc
> >    work. After it returns, in-flight receive processing has completed,
> >    and subsequent calls see gsm->dead and return early.
> >
> > Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
> > Signed-off-by: Zhenghang Xiao <kipreyyy@gmail.com>
> > ---
> >  drivers/tty/n_gsm.c | 13 +++++++++++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
>
> Cool, how did you test this?
>
>
> >
> > diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
> > index c13e050de83b..8322fffbaeba 100644
> > --- a/drivers/tty/n_gsm.c
> > +++ b/drivers/tty/n_gsm.c
> > @@ -3156,12 +3156,18 @@ static void gsm_cleanup_mux(struct gsm_mux *gsm, bool disc)
> >               gsm_unregister_devices(gsm_tty_driver, gsm->num);
> >               gsm->has_devices = false;
> >       }
> > +     /*
> > +      * Flush the ldisc before releasing DLCIs. tty_ldisc_flush() waits
> > +      * for any in-flight flush_to_ldisc work to complete via buf->lock,
> > +      * and the gsm->dead check added to gsmld_receive_buf() rejects any
> > +      * future receive processing. This ensures gsm_queue() cannot access
> > +      * a DLCI being freed.
> > +      */
> > +     tty_ldisc_flush(gsm->tty);
> >       for (i = NUM_DLCI - 1; i >= 0; i--)
> >               if (gsm->dlci[i])
> >                       gsm_dlci_release(gsm->dlci[i]);
> >       mutex_unlock(&gsm->mutex);
> > -     /* Now wipe the queues */
> > -     tty_ldisc_flush(gsm->tty);
> >
> >       guard(spinlock_irqsave)(&gsm->tx_lock);
> >       list_for_each_entry_safe(txq, ntxq, &gsm->tx_ctrl_list, list)
> > @@ -3604,6 +3610,9 @@ static void gsmld_receive_buf(struct tty_struct *tty, const u8 *cp,
> >       struct gsm_mux *gsm = tty->disc_data;
> >       u8 flags = TTY_NORMAL;
> >
> > +     if (gsm->dead)
> > +             return;
> > +
>
> What prevents dead from changing right after you test this?
>
> thanks,
>
> greg k-h

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH tty] tty: n_gsm: fix use-after-free in gsm_queue vs gsm_cleanup_mux race
  2026-05-29  6:28   ` Zhenghang Xiao
@ 2026-05-30  5:19     ` Greg KH
  0 siblings, 0 replies; 4+ messages in thread
From: Greg KH @ 2026-05-30  5:19 UTC (permalink / raw)
  To: Zhenghang Xiao; +Cc: jirislaby, linux-serial

On Fri, May 29, 2026 at 02:28:22PM +0800, Zhenghang Xiao wrote:
> Resending this email as plain text, since the previous reply was
> rejected by the mailing list for containing an HTML part.
> -------------------
> Thanks for your reply!
> 
> > How to test
> I built two identical arm64 kernels (v7.1.0-rc4), differing only by
> this patch. Both kernel carry a msleep(20) instrumentation in
> gsm_queue() to widen the race window. Then run PoC and the patched
> kernel do not report kASAN again.

What PoC?  Do you have the hardware that uses this ldisc?

> > What prevents dead from changing
> Nothing prevents it and it doesn't need to. tty_ldisc_flush() is the
> sync mechanism not dead check.
> If gsmld_receive_buf() is already past the check, it's running under
> buf->lock. The patch moves tty_ldisc_flush() before DLCI release. And
> tty_buffer_flush() acquires the same buf->lock, so it blocks until the
> in-flight receive completes. DLCIs are freed only after that.
> 
> The dead check handles the other direction, any receive that starts
> after the flush sees dead == true and returns early. But I'm not sure
> if silent drop here is fine or not.

I don't think dropping is ok, test this on real hardware to see what
happens.

Also, this should be 2 patches, not 1, right?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-05-30 10:25 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-26 10:29 [PATCH tty] tty: n_gsm: fix use-after-free in gsm_queue vs gsm_cleanup_mux race Zhenghang Xiao
2026-05-27  8:16 ` Greg KH
2026-05-29  6:28   ` Zhenghang Xiao
2026-05-30  5:19     ` Greg KH

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox