CVE-2026-74655: serial: qcom-geni: fix TX DMA buffer flush
In the Linux kernel, the following vulnerability has been resolved:
serial: qcom-geni: fix TX DMA buffer flush
When transmit flushing a qcom-geni UART during an ongoing TX DMA, the UART gets stuck infinitely repeating corrupted TX DMA frames.
The DMA-mode uartops does not provide a flushbuffer callback, so an in-flight transfer can complete after serial core has reset the transmit kfifo, underflowing its length and resubmitting page-sized transfers indefinitely. Add one that stops the transfer and clears txremaining and txqueued.
The stop path was also broken: it unmapped the buffer while the serial engine could still read it, and never reset the TX DMA state machine. Cancel the main sequencer command first, then reset the state machine and wait for it before unmapping. Drop the early return so a pending mapping is also cleaned up when the main command is inactive.
The bug can be triggered from userspace with a large write immediately followed by TCOFLUSH. A following tcdrain will hang forever. The bug was reproduced and this fix was validated on Arduino Uno Q (QRB2210) using /dev/ttyHS1.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using a qcom-geni UART in DMA mode are affected when transmit flushing occurs during an active TX DMA transfer. The issue was reproduced on an Arduino Uno Q (QRB2210) using /dev/ttyHS1.
What access and actions are needed to trigger the failure?
A userspace process needs access to the affected UART device node. The documented trigger is a large write immediately followed by TCOFLUSH while the transmit DMA is still in progress.
What symptoms indicate that the UART may already be stuck?
The UART can repeatedly transmit corrupted DMA frames indefinitely after the flush. A subsequent tcdrain call will hang forever.