CVE-2026-93168 Affecting kernel-syms package, versions <6.4.0-150700.53.90.1
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-SLES157-KERNELSYMS-22239053
- published5 Nov 2026
- disclosed3 Nov 2026
Introduced: 3 Nov 2026
NewCVE-2026-93168 (opens in a new tab)How to fix?
Upgrade SLES:15.7 kernel-syms to version 6.4.0-150700.53.90.1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-syms package and not the kernel-syms package as distributed by SLES.
See How to fix? for SLES:15.7 relevant fixed versions and status.
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
- https://www.suse.com/security/cve/CVE-2026-93168.html
- https://bugzilla.suse.com/1282151
- https://git.kernel.org/stable/c/8b5654d317277e6e505c23f8fa7e415237fefc7f
- https://git.kernel.org/stable/c/aa99c4d1d63bbc26a5fc4c667d89b2595743c19d
- https://git.kernel.org/stable/c/f786e7b3adbf3bd14964a1cedf9d55b6ad91dcd7
- https://git.kernel.org/stable/c/2ba67aa183a3ce174d534425b67eda84f6e3c896
- https://git.kernel.org/stable/c/c30a26d4987a01e619449bf170f584c007e07d75
- https://git.kernel.org/stable/c/4237b5cc181a17f5a2a797655c1ce2c64e01c550