All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Austin Schlegel" <schlegelas@outlook.com>
Cc: linux-serial@vger.kernel.org
Subject: Re: [PATCH v2 1/2] serial: tegra: fix RX DMA descriptor use-after-free
Date: Thu, 15 Oct 2026 03:43:30 +0000	[thread overview]
Message-ID: <sashiko-outbox-172217@kernel.org> (raw)
In-Reply-To: <20261014-serial-tegra-dma-uaf-v2-1-b142b31b67e3@outlook.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] tty: serial: tegra: DMA tasklets race with termination causing corruption
--

commit 829540ff4c493e2669ac25a22f37fd2da4f2c018
Author: Austin Schlegel <schlegelas@outlook.com>

serial: tegra: fix RX DMA descriptor use-after-free

This commit fixes a use-after-free by moving the async_tx_ack() call to
tegra_uart_rx_dma_complete() and tegra_uart_terminate_rx_dma() before the
descriptors are freed. It removes the ack from tegra_uart_rx_buffer_push()
where the descriptor is no longer safe to access.

Link: https://lore.kernel.org/all/20261001-tty-linus-v1-1-ecb8576c802d@arthrex.com/

> --- a/drivers/tty/serial/serial-tegra.c
> +++ b/drivers/tty/serial/serial-tegra.c

[ ... ]

> @@ -761,6 +760,7 @@ static void tegra_uart_rx_dma_complete(void *args)
>  		set_rts(tup, false);
>  
>  	tup->rx_dma_active = false;
> +	async_tx_ack(tup->rx_dma_desc);
>  	tegra_uart_rx_buffer_push(tup, 0);
>  	tegra_uart_start_rx_dma(tup);
>  

[Severity: High]
Can this callback race with concurrent DMA termination?

If tegra_uart_stop_rx() or tegra_uart_terminate_rx_dma() is called
concurrently (for instance, when userspace calls tcsetattr() or closes
the port while data is transferring), CPU 0 might terminate the DMA,
acknowledge the descriptor, and update the state. Meanwhile, CPU 1's DMA
completion tasklet could be spinning on the uart_port_lock.

Once CPU 1 acquires the lock, it appears to unconditionally execute this
block without checking if the channel was already intentionally terminated
(e.g., by checking if tup->rx_dma_active is still true). Could this
redundantly push buffers, erroneously access the potentially freed
descriptor via async_tx_ack(), and incorrectly restart the DMA?

Additionally, does a similar race condition exist in the TX path? In
tegra_uart_tx_dma_complete(), the callback accesses the descriptor outside
the lock and unconditionally advances the TX ring, which seems like it could
race destructively with tegra_uart_stop_tx().

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014-serial-tegra-dma-uaf-v2-0-b142b31b67e3@outlook.com?part=1

  reply	other threads:[~2026-10-15  3:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15  3:29 [PATCH v2 0/2] serial: tegra: fix RX/TX DMA descriptor use-after-free Austin Schlegel via B4 Relay
2026-10-15  3:29 ` Austin Schlegel
2026-10-15  3:30 ` [PATCH v2 1/2] serial: tegra: fix RX " Austin Schlegel via B4 Relay
2026-10-15  3:30   ` Austin Schlegel
2026-10-15  3:43   ` sashiko-bot [this message]
2026-10-15  3:30 ` [PATCH v2 2/2] serial: tegra: fix TX " Austin Schlegel via B4 Relay
2026-10-15  3:30   ` Austin Schlegel
2026-10-15  3:41   ` sashiko-bot

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-172217@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=schlegelas@outlook.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 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.