Cloudanix VulnDB

CVE-2026-93168

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's Xilinx DMA handling can make the processor get stuck busy-waiting for a long time when hardware does not respond as expected, potentially freezing parts of the system.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

CPU stall caused by busy-wait in xilinx_dma_poll_timeout when delay_us=0 and the polled condition is never met, due to severe underestimation of wall-clock time in poll_timeout_us_atomic leading to timeouts taking minutes instead of microseconds.

Why it matters to the business

Systems using Xilinx DMA in the Linux kernel may experience prolonged unresponsiveness or effective denial of service during DMA transfer initialization if hardware fails to meet expected conditions, impacting availability in affected embedded or server environments.

How an attack unfolds

An attacker or faulty hardware triggers repeated calls to xilinx_dma_poll_timeout with delay_us=0 while the completion condition remains false; the loop executes XILINX_DMA_LOOP_COUNT iterations without proper timing, consuming CPU for several minutes and stalling the system.

How to fix it

Apply the upstream kernel fix that introduces XILINX_DMA_POLL_DELAY_US set to 10 and replaces the zero delay in xilinx_dma_poll_timeout; rebuild and deploy the updated kernel image on affected systems.

How to confirm the fix worked

Confirm the presence of the constant XILINX_DMA_POLL_DELAY_US and updated call site in the xilinx_dma source; measure timeout duration under artificial failure conditions to verify it completes near the expected 1-second window rather than minutes.

Typical attack path

  1. Identify or induce a DMA transfer start that invokes xilinx_dma_poll_timeout
  2. Supply or force a condition that is never fulfilled (e.g., hardware failure or crafted input)
  3. Invoke the poll with delay_us explicitly set to 0
  4. Observe CPU consumption spike and delayed timeout leading to stall

How to detect it

Inspect kernel logs for repeated xilinx_dma entries or watchdog timeouts around DMA initialization; correlate with high CPU usage in poll loops via perf or ftrace during transfer setup.

What your security team should do

  • Prioritize kernel update for any systems using the xilinx_dma driver in production DMA paths
  • Monitor for CPU stalls or high utilization during DMA initialization after patching
  • Review downstream device drivers or user-space code that may call the affected poll routine with zero delay

The record

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.

Affected packages

Ecosystem Package Introduced Fixed