CVE-2026-93168

Vulnérabilité non évaluée dans Linux (Linux)

CVSS 0.0 · Non évaluée
EPSS 0.2%
Linux•Linux•Versions : 7.2.6, <=*, 4.6, <aa99c4d1d63bbc26a5fc4c667d89b2595743c19d, <f786e7b3adbf3bd14964a1cedf9d55b6ad91dcd7, 6.18.57, <=6.18.*, 9495f2648287029fb5545c34a0fa318426ebe84c, 0, <4.6, <=7.2.*, <8b5654d317277e6e505c23f8fa7e415237fefc7f, 7.3

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.

Gravité et risque d'exploitation

CVE-2026-93168 obtient un score CVSS de 0.0/10, soit une gravité non évaluée. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.17 %, ce qui la place devant 5.5 % des CVE référencées.

Que faire ?

  • Vérifiez si Linux (versions 7.2.6, <=*, 4.6, <aa99c4d1d63bbc26a5fc4c667d89b2595743c19d, <f786e7b3adbf3bd14964a1cedf9d55b6ad91dcd7, 6.18.57, <=6.18.*, 9495f2648287029fb5545c34a0fa318426ebe84c, 0, <4.6, <=7.2.*, <8b5654d317277e6e505c23f8fa7e415237fefc7f, 7.3) est présent sur votre parc.
  • Appliquez le correctif ou la version corrigée indiqués dans les références de l'éditeur.
  • À défaut de correctif, limitez l'exposition (filtrage réseau, désactivation du composant).
  • Automatisez la détection : les agents CVE Heimdall (gratuits, open source) corrèlent l'inventaire de vos serveurs avec la base CVE.

Références