dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
Summary
| CVE | CVE-2026-93168 |
|---|---|
| State | PUBLISHED |
| Assigner | Linux |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-09-17 17:18:12 UTC |
| Updated | 2026-09-17 17:18:12 UTC |
| Description | 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. |
Risk And Classification
EPSS: 0.001550000 probability, percentile 0.051260000 (date 2026-09-19)
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|---|---|---|---|
| CNA | Linux | Linux | affected 9495f2648287029fb5545c34a0fa318426ebe84c 8b5654d317277e6e505c23f8fa7e415237fefc7f git | Not specified |
| CNA | Linux | Linux | affected 9495f2648287029fb5545c34a0fa318426ebe84c aa99c4d1d63bbc26a5fc4c667d89b2595743c19d git | Not specified |
| CNA | Linux | Linux | affected 4.6 | Not specified |
| CNA | Linux | Linux | unaffected 4.6 semver | Not specified |
| CNA | Linux | Linux | unaffected 7.2.6 7.2.* semver | Not specified |
| CNA | Linux | Linux | unaffected 7.3-rc1 * original_commit_for_fix | Not specified |
References
| Reference | Source | Link | Tags |
|---|---|---|---|
| git.kernel.org/stable/c/8b5654d317277e6e505c23f8fa7e415237fefc7f | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | git.kernel.org | |
| git.kernel.org/stable/c/aa99c4d1d63bbc26a5fc4c667d89b2595743c19d | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | git.kernel.org | |
| CVE Program record | CVE.ORG | www.cve.org | canonical |
| NVD vulnerability detail | NVD | nvd.nist.gov | canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.