[PATCH 0/2] serial: tegra: fix RX/TX DMA descriptor use-after-free
From: Austin via B4 Relay
Date: Thu Oct 01 2026 - 15:05:35 EST
Both patches in this series fix the same bug pattern in
drivers/tty/serial/serial-tegra.c: dmaengine_terminate_all() is called
before async_tx_ack() on the DMA descriptor it just terminated. With
the GPC DMA driver (tegra186-gpc-dma.c, used on Tegra194/Tegra234),
terminating a channel frees the active descriptor synchronously via
vchan_dma_desc_free_list(), so the subsequent ack touches freed
memory. dmaengine clients are not allowed to touch a descriptor once
it has been terminated.
Patch 1/2 (RX) was found via a KFENCE use-after-free report on a
Jetson AGX Orin (Tegra234) under UART loopback traffic, and the fix
has since been soak tested for 24+ hours with
kfence.sample_interval=1 with zero further reports.
Patch 2/2 (TX) is the same ordering bug in the analogous TX path
(tegra_uart_stop_tx()), found by code inspection once the RX bug was
understood. It has not been reproduced on hardware - triggering it
requires stopping an in-flight TX DMA transfer at the right moment,
which did not occur during RX testing - but it is the identical
dmaengine_terminate_all()-then-ack pattern in the same driver against
the same DMA engine, so I'm sending it alongside the RX fix rather
than leaving it unfixed.
Both patches keep the pre-existing descriptor-leak fix from commit
b31245b94207 ("serial: tegra: ack the rx dma desc after transfer
terminated") intact: the ack still happens for every terminated
transfer, just before the descriptor is freed instead of after.
Testing was done on Tegra234 (Jetson AGX Orin) only.
Signed-off-by: Austin <austin.schlegel@xxxxxxxxxxx>
---
Austin (2):
serial: tegra: fix RX DMA descriptor use-after-free
serial: tegra: fix TX DMA descriptor use-after-free
drivers/tty/serial/serial-tegra.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
---
base-commit: 5dad87615c9861cfa366ca984b52f581e861df20
change-id: 20261001-tty-linus-ae90fc64265d
Best regards,
--
Austin <austin.schlegel@xxxxxxxxxxx>