Katalog CVE

CVE-2026-93168

Nieznane
Opublikowano: Przetłumaczono: NVD NIST

Streszczenie

W jądrze Linux w sterowniku dmaengine xilinx_dma funkcja xilinx_dma_poll_timeout wywoływana z parametrem delay_us=0 powodowała zajęte oczekiwanie CPU przez bardzo długi czas, gdy warunek zakończenia nigdy nie został spełniony. Zamiast przekroczyć limit czasu po około XILINX_DMA_LOOP_COUNT mikrosekund, przekroczenie następowało po kilku minutach, co prowadziło do zablokowania CPU. Poprawka wprowadza stałą XILINX_DMA_POLL_DELAY_US i używa delay_us=10.

Ocena ryzyka

W przypadku awarii sprzętowych DMA sterownik może zablokować CPU na kilka minut, powodując zawieszenie systemu lub niedostępność usług. Problem dotyczy systemów z kontrolerami DMA Xilinx.

Rekomendacja

Zaktualizuj jądro Linux do wersji zawierającej poprawkę dla CVE-2026-93168. Jeśli aktualizacja nie jest możliwa, unikaj konfiguracji powodujących wywołanie xilinx_dma_poll_timeout z delay_us=0.

Inne podatności w Linux kernel

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

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.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS