From: sashiko-bot@kernel.org
To: "Hengyu Liang" <hengyul@cs.unc.edu>
Cc: linux-serial@vger.kernel.org
Subject: Re: [PATCH] serial: core: fix TIOCSSERIAL and TIOCSERCONFIG on uninitialised ports
Date: Sat, 10 Oct 2026 03:59:03 +0000 [thread overview]
Message-ID: <sashiko-outbox-166251@kernel.org> (raw)
In-Reply-To: <20261010034616.3915864-1-hengyul@cs.unc.edu>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] serial: hw access without PM in uart_do_autoconfig()
--
commit f48636ab329a71ecd2a47c54111b53dd3b5b35da
Author: Hengyu Liang <hengyul@cs.unc.edu>
serial: core: fix TIOCSSERIAL and TIOCSERCONFIG on uninitialised ports
This commit changes the check in uart_set_info() and uart_do_autoconfig()
from tty_io_error() to tty_port_active(). This allows setserial to configure
a port that the kernel did not detect, fixing an issue where uninitialized
ports could not be configured.
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 319a4b427f3a3..36c59f5fadebd 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
[ ... ]
> @@ -1143,7 +1147,8 @@ static int uart_do_autoconfig(struct tty_struct *tty, struct uart_state *state)
> */
> scoped_cond_guard(mutex_intr, return -ERESTARTSYS, &port->mutex) {
> uport = uart_port_check(state);
> - if (!uport || tty_io_error(tty))
> + /* As in uart_set_info(), only refuse a hung up port. */
> + if (!uport || !tty_port_active(port))
> return -EIO;
[Severity: High]
Does relaxing this check to tty_port_active() allow the ioctl to proceed on
uninitialized (PORT_UNKNOWN) ports where the power management state is still
OFF?
A user with CAP_SYS_ADMIN could call open() on an uninitialized port which
succeeds but sets TTY_IO_ERROR. If they then invoke the TIOCSERCONFIG ioctl,
the active but uninitialized port would pass this check.
Further down in uart_do_autoconfig(), the code executes:
uport->ops->config_port(uport, flags);
Could this unconditionally invoke the driver's config_port callback before
uart_startup() has a chance to enable power and clocks? On architectures with
strict power domain management, accessing hardware registers without runtime
PM enabled can trigger a fatal bus error (synchronous external abort) and
kernel panic.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261010034616.3915864-1-hengyul@cs.unc.edu?part=1
next prev parent reply other threads:[~2026-10-10 3:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-10 3:46 [PATCH] serial: core: fix TIOCSSERIAL and TIOCSERCONFIG on uninitialised ports Hengyu Liang
2026-10-10 3:59 ` sashiko-bot [this message]
2026-10-10 6:16 ` Sasha Levin
2026-10-11 12:16 ` Johan Hovold
2026-10-11 15:00 ` Hengyu Liang
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-166251@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=hengyul@cs.unc.edu \
--cc=linux-serial@vger.kernel.org \
--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.