---
id: CVE-2026-93168
title: |-
  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,…
summary: |-
  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,…
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 9495f2648287029fb5545c34a0fa318426ebe84c <
    8b5654d317277e6e505c23f8fa7e415237fefc7f
  - >-
    Linux >= 9495f2648287029fb5545c34a0fa318426ebe84c <
    aa99c4d1d63bbc26a5fc4c667d89b2595743c19d
  - Linux 4.6
published: '2026-09-17'
updated: '2026-09-17'
sourceUpdated: '2026-09-17T17:18:12.403'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2026-93168'
references:
  - url: 'https://git.kernel.org/stable/c/8b5654d317277e6e505c23f8fa7e415237fefc7f'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/aa99c4d1d63bbc26a5fc4c667d89b2595743c19d'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
tags:
  - nvd
  - cve.org
ingestedAt: '2026-09-17T16:21:47.732Z'
epss: 0.00198
epssPercentile: 0.08468
---

## Overview

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.

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.