CVE-2026-93168: Linux kernel · dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
Affects Linux kernelSource CVE Database V5
Not known to be exploited · fixed in f786e7b3adbf3bd14964a1cedf9d55b6ad91dcd7 : update Linux kernel when convenient.
Data as of 26 Oct 2026, 13:47 UTC
Rated by Threat Radar · CVSS not yet scored by NVD
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 6% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in f786e7b3adbf3bd14964a1cedf9d55b6ad91dcd7, c30a26d4987a01e619449bf170f584c007e07d75, aa99c4d1d63bbc26a5fc4c667d89b2595743c19d +2
Exploitation evidence
Disclosed: evidence found.
CVE published 17 Sep 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in– |
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.
References
- git.kernel.org/stable/c/2ba67aa183a3ce174d534425b67eda84f6e3c896 (opens in a new tab)
- git.kernel.org/stable/c/c30a26d4987a01e619449bf170f584c007e07d75 (opens in a new tab)
- git.kernel.org/stable/c/f786e7b3adbf3bd14964a1cedf9d55b6ad91dcd7 (opens in a new tab)
- git.kernel.org/stable/c/8b5654d317277e6e505c23f8fa7e415237fefc7f (opens in a new tab)
- git.kernel.org/stable/c/aa99c4d1d63bbc26a5fc4c667d89b2595743c19d (opens in a new tab)