CVE-2026-93168: dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: xilinxdma: Fix CPU stall in xilinxdmapolltimeout
Currently when calling xilinxdmapolltimeout with delayus=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 polltimeoutusatomic. Commit 7349a69cf312 ("iopoll: Do not use timekeeping in readpolltimeoutatomic()") changed the behavior to no longer use ktimeget at the expense of underestimation of wall clock time which appears to be very large for delayus=0. Instead of timing out after approximately XILINXDMALOOPCOUNT microseconds, the timeout takes XILINXDMALOOPCOUNT 1000 (time that the overhead of the for loop in polltimeoutusatomic takes) which is in the range of several minutes for XILINXDMALOOPCOUNT=1000000. Fix this by using a non-zero value for delayus. Use delayus=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 delayus=0 causes the cpu to busy wait around 7 minutes in the timeout case. After applying this patch with delayus=10 the measured timeout was 1053428 microseconds which is roughly equivalent to the expected 1000000 microseconds specified in XILINXDMALOOPCOUNT.
Add a constant XILINXDMAPOLLDELAYUS for delayus value.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
dmaengine: xilinx_dmato a version that resolves this vulnerability.Patch 7349a69cf312 - Configuration
Define/add constant XILINX_DMA_POLL_DELAY_US with delay_us=10 (per commit 7349a69cf312: “iopoll: Do not use …”); use this non-zero delay to prevent CPU busy-wait/stall when calling xilinx_dma_poll_timeout with delay_us=0.
iopoll/xilinx_dma_poll_timeout XILINX_DMA_POLL_DELAY_US = 10
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Linux kernel systems using the Xilinx DMA driver are exposed when xilinx_dma_poll_timeout is called with a zero-microsecond delay and the expected condition is never met, such as during an unexpected hardware failure.
What is required to trigger the CPU stall?
The polling path must use delay_us=0 and continue waiting for a condition that is never fulfilled. Under those circumstances, the CPU busy-waits and the intended timeout can be delayed from approximately the loop-count duration to several minutes.
Is normal DMA startup performance materially affected by the fix?
The fix uses a 10-microsecond polling delay. This is intended to keep the delay in the DMA transfer startup hot path minimal while preventing prolonged CPU busy-waiting when hardware does not respond.
What changes address the issue?
Apply a kernel version containing the Xilinx DMA fix referenced by stable commits 8b5654d317277e6e505c23f8fa7e415237fefc7f or aa99c4d1d63bbc26a5fc4c667d89b2595743c19d. The correction changes the polling delay from zero to 10 microseconds.