When flushing a qcom-geni UART during an ongoing transmit DMA, the UART becomes stuck in an infinite cycle that repeatedly sends corrupted DMA frames. The driver’s DMA-mode operations lack a proper flush callback, so an in-flight transfer can complete after the serial core resets the transmit FIFO, underflowing the buffer length and causing the driver to resubmit page-sized transfers endlessly. The stop path is also defective: it unmapped the buffer while the serial engine may still access it and never resets the TX DMA state machine, so the asynchronous cleanup never completes. This combination leads to a hang that manifests when a large write is immediately followed by the TCOFLUSH ioctl and an ensuing tcdrain, which blocks forever.

The flaw resides in the Linux kernel’s qcom‑geni UART driver. Systems that run a kernel version containing the unpatched driver and rely on qcom‑geni UART devices—examples include the Arduino Uno Q (QRB2210) using /dev/ttyHS1—are susceptible. Any Linux installation that incorporates the affected driver code before the patch will be affected.

The EPSS score of < 1% indicates a very low probability of exploitation. The CVSS score of 8.8 marks this as a high severity local denial of service. The vulnerability is not listed in CISA’s KEV catalog, implying limited evidence of exploitation. The attack vector is local: any userspace process on a system running an unpatched kernel can trigger the condition by performing a large write to a qcom‑geni UART followed by a TCOFLUSH ioctl and then a tcdrain, leading to an infinite loop that stalls the UART driver.