From: Alex Elder <elder@linaro.org>
To: Johan Hovold <johan@kernel.org>, David Lin <dtwlin@gmail.com>,
Alex Elder <elder@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: greybus-dev@lists.linaro.org, linux-staging@lists.linux.dev,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [greybus-dev] [PATCH] staging: greybus: uart: fix tty use after free
Date: Tue, 7 Sep 2021 08:32:25 -0500 [thread overview]
Message-ID: <56782caa-bd9d-b049-7ca6-c64e3fbe109a@linaro.org> (raw)
In-Reply-To: <20210906124538.22358-1-johan@kernel.org>
On 9/6/21 7:45 AM, Johan Hovold wrote:
> User space can hold a tty open indefinitely and tty drivers must not
> release the underlying structures until the last user is gone.
>
> Switch to using the tty-port reference counter to manage the life time
> of the greybus tty state to avoid use after free after a disconnect.
>
> Fixes: a18e15175708 ("greybus: more uart work")
> Cc: stable@vger.kernel.org # 4.9
> Signed-off-by: Johan Hovold <johan@kernel.org>
I have a couple of minor comments. I assume the
tty model matches normal patterns for get/put and
reference counted objects, and based on that I'm
ready to give a Reviewed-by, but I'd like to hear
your responses first.
-Alex
> ---
> drivers/staging/greybus/uart.c | 62 ++++++++++++++++++----------------
> 1 file changed, 32 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c
> index 73f01ed1e5b7..a943fce322be 100644
> --- a/drivers/staging/greybus/uart.c
> +++ b/drivers/staging/greybus/uart.c
> @@ -761,6 +761,17 @@ static void gb_tty_port_shutdown(struct tty_port *port)
> gbphy_runtime_put_autosuspend(gb_tty->gbphy_dev);
> }
>
> +static void gb_tty_port_destruct(struct tty_port *port)
> +{
> + struct gb_tty *gb_tty = container_of(port, struct gb_tty, port);
> +
So the minor number is GB_NUM_MINORS until after both the buffer
and the kfifo have been allocated. And kfifo_free() (similar to
kfree()) handles being provided a non-initialized kfifo, correct?
> + if (gb_tty->minor != GB_NUM_MINORS)
> + release_minor(gb_tty);
> + kfifo_free(&gb_tty->write_fifo);
> + kfree(gb_tty->buffer);
> + kfree(gb_tty);
> +}
> +
> static const struct tty_operations gb_ops = {
> .install = gb_tty_install,
> .open = gb_tty_open,
> @@ -786,6 +797,7 @@ static const struct tty_port_operations gb_port_ops = {
> .dtr_rts = gb_tty_dtr_rts,
> .activate = gb_tty_port_activate,
> .shutdown = gb_tty_port_shutdown,
> + .destruct = gb_tty_port_destruct,
> };
>
> static int gb_uart_probe(struct gbphy_device *gbphy_dev,
> @@ -798,17 +810,11 @@ static int gb_uart_probe(struct gbphy_device *gbphy_dev,
> int retval;
> int minor;
>
> - gb_tty = kzalloc(sizeof(*gb_tty), GFP_KERNEL);
> - if (!gb_tty)
> - return -ENOMEM;
> -
Why do you reorder when you allocate the gb_tty structure?
I don't have a problem with it, but it seems like the order
doesn't matter. Is it just so you can initialize it right
after it's allocated? (If so, I like that reason.)
> connection = gb_connection_create(gbphy_dev->bundle,
> le16_to_cpu(gbphy_dev->cport_desc->id),
> gb_uart_request_handler);
> - if (IS_ERR(connection)) {
> - retval = PTR_ERR(connection);
> - goto exit_tty_free;
> - }
> + if (IS_ERR(connection))
> + return PTR_ERR(connection);
>
> max_payload = gb_operation_get_payload_size_max(connection);
> if (max_payload < sizeof(struct gb_uart_send_data_request)) {
> @@ -816,13 +822,23 @@ static int gb_uart_probe(struct gbphy_device *gbphy_dev,
> goto exit_connection_destroy;
> }
>
> + gb_tty = kzalloc(sizeof(*gb_tty), GFP_KERNEL);
> + if (!gb_tty) {
> + retval = -ENOMEM;
> + goto exit_connection_destroy;
> + }
> +
> + tty_port_init(&gb_tty->port);
> + gb_tty->port.ops = &gb_port_ops;
> + gb_tty->minor = GB_NUM_MINORS;
> +
> gb_tty->buffer_payload_max = max_payload -
> sizeof(struct gb_uart_send_data_request);
>
> gb_tty->buffer = kzalloc(gb_tty->buffer_payload_max, GFP_KERNEL);
> if (!gb_tty->buffer) {
> retval = -ENOMEM;
> - goto exit_connection_destroy;
> + goto exit_put_port;
> }
>
> INIT_WORK(&gb_tty->tx_work, gb_uart_tx_write_work);
> @@ -830,7 +846,7 @@ static int gb_uart_probe(struct gbphy_device *gbphy_dev,
> retval = kfifo_alloc(&gb_tty->write_fifo, GB_UART_WRITE_FIFO_SIZE,
> GFP_KERNEL);
> if (retval)
> - goto exit_buf_free;
> + goto exit_put_port;
>
> gb_tty->credits = GB_UART_FIRMWARE_CREDITS;
> init_completion(&gb_tty->credits_complete);
> @@ -844,7 +860,7 @@ static int gb_uart_probe(struct gbphy_device *gbphy_dev,
> } else {
> retval = minor;
> }
> - goto exit_kfifo_free;
> + goto exit_put_port;
> }
>
> gb_tty->minor = minor;
> @@ -853,9 +869,6 @@ static int gb_uart_probe(struct gbphy_device *gbphy_dev,
> init_waitqueue_head(&gb_tty->wioctl);
> mutex_init(&gb_tty->mutex);
>
> - tty_port_init(&gb_tty->port);
> - gb_tty->port.ops = &gb_port_ops;
> -
> gb_tty->connection = connection;
> gb_tty->gbphy_dev = gbphy_dev;
> gb_connection_set_data(connection, gb_tty);
> @@ -863,7 +876,7 @@ static int gb_uart_probe(struct gbphy_device *gbphy_dev,
>
> retval = gb_connection_enable_tx(connection);
> if (retval)
> - goto exit_release_minor;
> + goto exit_put_port;
>
> send_control(gb_tty, gb_tty->ctrlout);
>
> @@ -890,16 +903,10 @@ static int gb_uart_probe(struct gbphy_device *gbphy_dev,
>
> exit_connection_disable:
> gb_connection_disable(connection);
> -exit_release_minor:
> - release_minor(gb_tty);
> -exit_kfifo_free:
> - kfifo_free(&gb_tty->write_fifo);
> -exit_buf_free:
> - kfree(gb_tty->buffer);
> +exit_put_port:
> + tty_port_put(&gb_tty->port);
> exit_connection_destroy:
> gb_connection_destroy(connection);
> -exit_tty_free:
> - kfree(gb_tty);
>
> return retval;
> }
> @@ -930,15 +937,10 @@ static void gb_uart_remove(struct gbphy_device *gbphy_dev)
> gb_connection_disable_rx(connection);
> tty_unregister_device(gb_tty_driver, gb_tty->minor);
>
> - /* FIXME - free transmit / receive buffers */
> -
> gb_connection_disable(connection);
> - tty_port_destroy(&gb_tty->port);
> gb_connection_destroy(connection);
> - release_minor(gb_tty);
> - kfifo_free(&gb_tty->write_fifo);
> - kfree(gb_tty->buffer);
> - kfree(gb_tty);
> +
> + tty_port_put(&gb_tty->port);
In the error path above, you call tty_port_put()
before calling gb_connection_destroy(), which matches
(in reverse) the order in which they're created. I'm
accustomed to having the order of the calls here match
the error path. Is this difference intentional? (It
shouldn't really matter.)
-Alex
> }
>
> static int gb_tty_init(void)
>
next prev parent reply other threads:[~2021-09-07 13:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-06 12:45 Johan Hovold
2021-09-07 13:32 ` Alex Elder [this message]
2021-09-08 7:56 ` [greybus-dev] " Johan Hovold
2021-09-08 12:16 ` Alex Elder
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=56782caa-bd9d-b049-7ca6-c64e3fbe109a@linaro.org \
--to=elder@linaro.org \
--cc=dtwlin@gmail.com \
--cc=elder@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=greybus-dev@lists.linaro.org \
--cc=johan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=stable@vger.kernel.org \
/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
all inboxes | Powered by JetHome®