CVE-2026-93123 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
serial: qcom-geni: do not advance stale DMA completions
The qcom GENI serial DMA TX completion path advances the transmit fifo by the number of bytes recorded in port->tx_remaining.
If uart_flush_buffer() runs after the hardware has completed a DMA transfer but before the DMA completion interrupt has been handled, the serial core resets the transmit fifo while port->tx_remaining still describes the old DMA transfer.
A previous fix avoided advancing an empty fifo by checking that the fifo length is at least tx_remaining. That still does not distinguish the old DMA payload from new bytes written after the flush. If userspace writes new data before the stale DMA completion interrupt is handled, the fifo can again contain at least tx_remaining bytes and the stale completion can advance and discard those new bytes.
Mark an in-flight DMA transfer stale when the transmit fifo is flushed. The later completion still unprepares the original DMA mapping using the saved length, but it no longer advances the transmit fifo.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The Qualcomm GENI serial driver within the Linux kernel contains a race condition vulnerability related to the handling of Direct Memory Access (DMA) transmission completions and buffer flushing operations. This issue arises from an inconsistency between the state tracked by the software driver, specifically the tx_remaining variable which records bytes pending in a DMA transfer, and the actual hardware FIFO status after a flush operation is initiated. The core flaw lies in the completion handler for TX DMA transfers, which blindly advances the transmit FIFO based on the number of bytes recorded in port->tx_remaining without verifying whether this data corresponds to currently active or stale transactions. This lack of state validation creates a window where software actions can inadvertently corrupt ongoing hardware operations or discard valid user data.
The vulnerability manifests through a specific sequence of events involving concurrent access patterns between the serial core and the DMA completion interrupt handler. When uart_flush_buffer is executed, typically triggered by terminal line discipline commands such as flushing input or output buffers, it resets the transmit FIFO to clear any pending data. However, if this flush occurs after hardware has completed a previous DMA transfer but before the corresponding DMA completion interrupt has been serviced, port->tx_remaining still holds the byte count for that now-completed transaction. A prior mitigation attempted to address similar issues by checking if the FIFO length was at least tx_remaining before advancing it. While this prevented underflow errors when the FIFO was empty, it failed to distinguish between bytes belonging to the old DMA transfer and new data written into the buffer after the flush operation began.
This oversight leads to a critical operational impact where valid user-space data can be silently discarded. If an application writes new serial data to the device immediately following a flush but before the stale DMA completion interrupt is handled, the FIFO will contain at least tx_remaining bytes of this fresh data. When the delayed interrupt finally fires, the driver interprets these new bytes as part of the old transaction and advances the transmit pointer by that amount. Consequently, the newly written data is effectively removed from the transmission queue without being sent to the hardware, resulting in a loss of communication integrity. This behavior can cause significant disruptions in serial communications, particularly in systems relying on precise timing or high-throughput data streams where flush operations are frequent.
From a security and standards perspective, this vulnerability aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, as the race condition stems from inadequate locking or state management between the buffer flushing mechanism and the DMA completion handler. It also relates to CWE-459, Incomplete Cleanup, because the driver fails to properly reset its internal tracking variables when a flush operation invalidates pending transactions. Furthermore, this type of logic error in kernel drivers can be leveraged for Denial of Service (DoS) attacks by causing persistent data loss or system instability, mapping to ATT&CK technique T1499, Endpoint Denial of Service. The flaw highlights the complexity of managing hardware state transitions in asynchronous environments and underscores the necessity for strict synchronization primitives when modifying shared resources like DMA buffers and FIFO pointers.
The resolution involves marking an in-flight DMA transfer as stale whenever a transmit flush operation is initiated. By setting a flag or updating internal state to indicate that any pending completion interrupts should no longer affect the current transmission pointer, the driver ensures that delayed completions do not interfere with new data. Although the interrupt handler will still unprepare the original DMA mapping using the saved length to release resources correctly, it will skip the step of advancing the transmit FIFO. This approach preserves the integrity of newly written data while ensuring proper resource cleanup for completed hardware operations. Implementing this fix requires careful attention to memory barriers and lock ordering to prevent new race conditions from being introduced during the state update process.
To mitigate similar vulnerabilities in other drivers or systems, developers should ensure that any operation which invalidates pending hardware transactions also updates all associated software state variables atomically with respect to interrupt handlers. It is crucial to distinguish between logical completion of a transfer and the actual processing of its completion event. Synchronization mechanisms such as spinlocks must protect both the flush path and the DMA completion handler, ensuring that checks for FIFO emptiness or validity are performed under consistent locking contexts. Additionally, implementing robust state machines that track whether a DMA transaction is active, completed, or invalidated can prevent stale completions from causing data corruption. Regular code audits focusing on race conditions in interrupt-driven subsystems are essential to maintaining the reliability of kernel-level serial communication drivers.