CVE-2026-93168 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
Currently when calling xilinx_dma_poll_timeout with delay_us=0 and a condition that is never fulfilled, the CPU busy-waits for prolonged time and the timeout triggers only with a massive delay causing a CPU stall.
This happens due to a huge underestimation of wall clock time in poll_timeout_us_atomic. Commit 7349a69cf312 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()") changed the behavior to no longer use ktime_get at the expense of underestimation of wall clock time which appears to be very large for delay_us=0. Instead of timing out after approximately XILINX_DMA_LOOP_COUNT microseconds, the timeout takes XILINX_DMA_LOOP_COUNT * 1000 * (time that the overhead of the for loop in poll_timeout_us_atomic takes) which is in the range of several minutes for XILINX_DMA_LOOP_COUNT=1000000. Fix this by using a non-zero value for delay_us. Use delay_us=10 to keep the delay in the hot path of starting DMA transfers minimal but still avoid CPU stalls in case of unexpected hardware failures.
One-off measurement with delay_us=0 causes the cpu to busy wait around 7 minutes in the timeout case. After applying this patch with delay_us=10 the measured timeout was 1053428 microseconds which is roughly equivalent to the expected 1000000 microseconds specified in XILINX_DMA_LOOP_COUNT.
Add a constant XILINX_DMA_POLL_DELAY_US for delay_us value.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel's xilinx_dma driver contains a critical timing flaw within its polling mechanism that can lead to severe system performance degradation and potential denial of service conditions. The vulnerability resides in the implementation of the poll_timeout function used by the Xilinx DMA engine, specifically affecting scenarios where hardware operations fail to complete within expected timeframes or when specific parameter configurations are utilized during driver initialization or runtime operation. This issue stems from a regression introduced by an earlier commit that sought to optimize polling performance by removing reliance on high-resolution kernel timekeeping functions in atomic contexts. While this optimization was intended to reduce overhead, it inadvertently caused a significant miscalculation of elapsed wall-clock time when the delay parameter is set to zero.
The technical root cause involves the interaction between the loop count configuration and the timing logic within poll_timeout_us_atomic. When the driver invokes xilinx_dma_poll_timeout with a delay value of zero microseconds, the underlying atomic polling routine fails to account for the actual passage of real-world time accurately due to the absence of proper timekeeping calls that were removed in previous optimizations. Consequently, instead of terminating after approximately one million microseconds as defined by the XILINX_DMA_LOOP_COUNT constant, the system enters a prolonged busy-wait state. In practical measurements, this flaw results in CPU stalls lasting up to seven minutes per occurrence, effectively freezing the processing core and preventing it from handling other tasks or interrupts during that interval.
From an operational impact perspective, this vulnerability poses a significant risk to system stability and availability. A single instance of triggering this condition can cause noticeable latency spikes across the entire operating system, as the affected CPU core remains occupied in tight loops without yielding control to the scheduler for extended periods. In embedded systems or real-time applications relying on Xilinx hardware acceleration, such delays can lead to missed deadlines, data loss, or complete application hangs. Furthermore, if this condition is triggered repeatedly through automated processes or malicious input that forces repeated DMA operations with faulty conditions, it could be exploited to create a sustained denial of service against the host system resources without requiring elevated privileges beyond those needed to initiate DMA transfers.
To mitigate this vulnerability and restore correct timing behavior, the fix involves modifying the polling logic to enforce a non-zero delay value during execution. Specifically, introducing a constant XILINX_DMA_POLL_DELAY_US with a value of ten microseconds ensures that the timeout mechanism functions as intended while maintaining minimal overhead in the critical path for starting DMA transfers. This adjustment allows the kernel scheduler to periodically regain control and prevents the massive underestimation of elapsed time that leads to multi-minute stalls. The measured outcome after applying this patch demonstrates that timeouts now occur at approximately one million microseconds, aligning with expected hardware behavior and eliminating the dangerous busy-wait loops associated with zero-delay configurations.
This issue is categorized under CWE-397 which addresses the declaration of variables without initialization or improper handling leading to unexpected states, though more specifically it relates to timing inconsistencies in resource management that cause performance degradation akin to CWE-400 concerning uncontrolled resource consumption through busy waiting. In terms of adversarial tactics, this vulnerability aligns with ATT&CK technique T1529 which involves system shutdown and reboot via denial of service conditions caused by exhausting resources or causing hangs. Security practitioners should ensure that kernel updates incorporating these fixes are applied promptly to embedded systems utilizing Xilinx DMA engines, particularly in environments where high availability and real-time processing capabilities are critical requirements for operational continuity.