CVE-2026-74655 in Linux
Summary
by MITRE • 08/22/2026
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 uart_ops does not provide a flush_buffer 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 tx_remaining and tx_queued.
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The vulnerability identified in the Linux kernel's Qualcomm GENI serial driver, specifically within the qcom-geni UART implementation, represents a critical flaw in how hardware state is managed during transmission buffer flushing operations. This issue stems from an incomplete synchronization between the software-level serial core and the underlying DMA engine when handling transmit flush requests. The root cause lies in the absence of a dedicated flush_buffer callback for the DMA-mode uart_ops structure. Without this specific handler, the kernel's serial infrastructure lacks the mechanism to properly halt active Direct Memory Access transfers before resetting internal data structures. Consequently, when an application initiates a buffer flush while a transmission is actively underway via DMA, the system proceeds to reset the transmit kfifo without first stopping the hardware engine. This race condition allows in-flight DMA descriptors to complete their operations even after the software has cleared its tracking of pending bytes, leading to a state where the driver attempts to resubmit page-sized transfers with underflowed length parameters indefinitely.
From an operational perspective, this flaw results in severe system instability and resource exhaustion. The UART controller becomes trapped in an infinite loop, continuously generating corrupted TX DMA frames that consume bus bandwidth and CPU cycles associated with interrupt handling or polling mechanisms. For end-users and administrators, the manifestation of this bug is a complete hang of serial communication channels. Specifically, when triggered by a large write operation immediately followed by a TCOFLUSH ioctl call, subsequent calls to tcdrain will block indefinitely because the driver never successfully clears its transmission state. This effectively denies service for any application relying on that specific UART port, such as console access or industrial control interfaces running on devices like the Arduino Uno Q based on the QRB2210 chipset. The inability to drain buffers or reset ports can lead to cascading failures in higher-level protocols dependent on reliable serial I/O.
The technical remediation involves a comprehensive overhaul of the stop and flush logic within the driver's DMA handling routines. First, a new flush_buffer callback is implemented to explicitly halt ongoing transfers and clear critical state variables such as tx_remaining and tx_queued before any FIFO reset occurs. Second, the sequence for stopping transmission was corrected to address unsafe memory access patterns. Previously, the code would unmap the DMA buffer while the serial engine might still be reading from it, creating a potential use-after-free scenario or hardware fault. The fix mandates that the main sequencer command is cancelled first, followed by resetting the TX DMA state machine and waiting for its completion before unmapping buffers. Additionally, logic was added to ensure pending mappings are cleaned up even if the main command is inactive, preventing resource leaks during error paths.
This vulnerability aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition), as it involves a race between software state updates and hardware DMA completion events. It also relates to CWE-401, Missing Release of Memory after Effective Lifetime, due to the improper handling of buffer mappings during error or flush scenarios where resources are not correctly released or reset. In terms of attack vectors, this could be leveraged for Denial of Service (DoS) attacks by unprivileged users with write access to the serial device node, mapping to MITRE ATT&CK technique T1499, Endpoint Denial of Service. Mitigation strategies include applying the kernel patch that introduces the flush_buffer callback and corrects the DMA stop sequence. System administrators should ensure their kernels are updated to versions containing this fix, particularly if they utilize Qualcomm-based platforms with GENI serial controllers. For environments where immediate patching is not feasible, restricting write permissions on affected tty devices can mitigate the risk of exploitation by non-root users.