From: sashiko-bot@kernel.org
To: "Mehmet Fide" <mehmet.fide@gmail.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH] usb: gadget: u_serial: implement flush_buffer
Date: Thu, 15 Oct 2026 16:42:47 +0000 [thread overview]
Message-ID: <sashiko-outbox-173201@kernel.org> (raw)
In-Reply-To: <20261015162732.3170938-1-mehmet.fide@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] tty: u_serial: UAF in gs_flush_buffer during TTY hangup
--
commit c239a0119a25b9f8fab856b838b114d124d55f62
Author: Mehmet Fide <mehmet.fide@screeningeagle.com>
usb: gadget: u_serial: implement flush_buffer
This patch implements flush_buffer for u_serial to discard buffered output
under the port lock. This aims to prevent gs_close() from blocking for the
full 15-second timeout when the host does not read the port.
> diff --git a/drivers/usb/gadget/function/u_serial.c b/drivers/usb/gadget/function/u_serial.c
> index cdd1dfc666c4f..2b99e33cbf3af 100644
> --- a/drivers/usb/gadget/function/u_serial.c
> +++ b/drivers/usb/gadget/function/u_serial.c
> @@ -822,6 +822,19 @@ static void gs_flush_chars(struct tty_struct *tty)
> spin_unlock_irqrestore(&port->port_lock, flags);
> }
>
> +static void gs_flush_buffer(struct tty_struct *tty)
> +{
> + struct gs_port *port = tty->driver_data;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&port->port_lock, flags);
[Severity: High]
Could this lead to a use-after-free during TTY hangup?
If a USB gadget unbinds, gserial_disconnect() schedules a hangup via
tty_hangup(), which queues hangup_work. Concurrently, if userspace closes
the TTY, tty_release() calls gs_close(), dropping port->count to 0. This
wakes up gserial_free_port(), which proceeds to kfree(port).
Once tty_release() drops tty_lock(), the scheduled hangup_work executing
__tty_hangup() can acquire tty_lock() and call tty_ldisc_hangup().
Because tty_ldisc_hangup() unconditionally calls tty_driver_flush_buffer()
if a line discipline is present, it will invoke this newly added callback. By
this point, the port structure has already been freed by gserial_free_port(),
so attempting to take port->port_lock here dereferences freed memory.
> + kfifo_reset(&port->port_write_buf);
> + spin_unlock_irqrestore(&port->port_lock, flags);
> +
> + wake_up_interruptible(&port->drain_wait);
> + tty_wakeup(tty);
> +}
> +
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261015162732.3170938-1-mehmet.fide@gmail.com?part=1
next prev parent reply other threads:[~2026-10-15 16:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 16:27 [PATCH] usb: gadget: u_serial: implement flush_buffer Mehmet Fide
2026-10-15 16:42 ` sashiko-bot [this message]
2026-10-15 19:41 ` Mehmet Fide
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=sashiko-outbox-173201@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mehmet.fide@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
/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.