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.
Published: 2026-09-17
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service via CPU stall
Action: Immediate Patch
AI Analysis

Impact

The vulnerability arises when the Xilinx DMA driver’s poll timeout routine is invoked with a zero microsecond delay and a condition that never meets its exit criterion. The driver then busy‑waits for an excessive period—on the order of minutes—before the timeout occurs, effectively stalling the CPU. This manifests as a denial of service on the affected system, potentially affecting all processes that require DMA operations and overall system responsiveness. The underlying weakness is a logical error that leads to unchecked resource consumption.

Affected Systems

This flaw affects the Linux kernel’s Xilinx DMA driver. While specific kernel release versions are not enumerated in the data, any installation that includes the unpatched xilinx_dma module on a Linux system is potentially vulnerable. Systems running embedded devices or servers that rely on Xilinx DMA for data transfer should review their kernel source and applied patches for this defect.

Risk and Exploitability

The EPSS score is reported as less than 1 %, indicating a very low likelihood of active exploitation, and the vulnerability is not listed in CISA’s KEV catalog. Nonetheless, an attacker with local or remote access could trigger the stall by orchestrating a DMA operation that never satisfies the poll condition, leading to prolonged CPU utilization. Without an official CVSS score available, the risk is assessed as moderate: the impact is significant on availability, but the probability of exploitation remains low at present.

Generated by OpenCVE AI on September 19, 2026 at 07:34 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the kernel update that incorporates the xilinx_dma_poll_timeout patch, which changes the minimum delay to 10 µs.
  • Upgrade to a kernel version that includes the revised Xilinx DMA driver or apply the backport that defines XILINX_DMA_POLL_DELAY_US as 10 µs.
  • If an immediate kernel upgrade is not possible, modify or rebuild the driver to use a non‑zero delay (e.g., 10 µs) in the poll_timeout routine so that the CPU does not become trapped in a lengthy busy‑wait.

Generated by OpenCVE AI on September 19, 2026 at 07:34 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 19 Sep 2026 08:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-399

Thu, 17 Sep 2026 16:30:00 +0000

Type Values Removed Values Added
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.
Title dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-17T16:11:59.904Z

Reserved: 2026-09-17T16:02:15.090Z

Link: CVE-2026-93168

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-17T17:18:12.403

Modified: 2026-09-17T17:18:12.403

Link: CVE-2026-93168

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-19T17:45:17Z

Weaknesses