serial: pch_uart: possible RX DMA buffer use-after-free during shutdow

[LI xiao]

Hello,

I found a possible race in the PCH UART driver's shutdown path and would appreciate your advice on whether the current ordering is safe.

In drivers/tty/serial/pch_uart.c, pch_uart_shutdown() disables the UART interrupts and resets the FIFO, then calls pch_free_dma() before free_irq():

pch_uart_hal_disable_interrupt(priv, PCH_UART_HAL_ALL_INT);
pch_uart_hal_fifo_reset(priv, PCH_UART_HAL_CLR_ALL_FIFO);
...
pch_free_dma(port);
free_irq(priv->port.irq, priv);

When DMA is enabled, pch_free_dma() releases the RX DMA channel and frees the coherent RX buffer using dma_free_coherent().

However, the IRQ handler pch_uart_interrupt() acquires uart_port_lock(&priv->port) and may call dma_handle_rx(), which accesses priv->rx_buf_virt to construct the scatterlist. I do not see pch_uart_shutdown() acquiring the same port lock before releasing the DMA resources.

My concern is that an IRQ handler already executing on another CPU could still access the RX buffer while pch_free_dma() frees it. The subsequent free_irq() occurs only after the buffer has been freed, and the serial core calls synchronize_irq() after the driver's shutdown callback returns.

Could you confirm whether this ordering can result in a race where the IRQ handler accesses the freed RX buffer, or whether an existing locking or lifecycle guarantee makes the current implementation safe?

I have not reproduced this issue at runtime. The QEMU environment available to me does not emulate the PCH EG20T UART, and I do not have matching hardware for a KASAN test.

I observed this ordering in Linux 6.18.1 and verified that the relevant code in the current mainline source remains unchanged from commit c03c1a14507dfaf8b856c2608f9ac216021fc222.

I have not prepared a patch because I would first like to confirm whether this race is possible.

Thanks,
LI Xiao