CVE-2025-38595 Affecting dlm-kmp-default package, versions <6.4.0-150600.23.73.1


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.03% (6th percentile)

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-SLES156-DLMKMPDEFAULT-13580597
  • published16 Oct 2025
  • disclosed15 Oct 2025

Introduced: 15 Oct 2025

NewCVE-2025-38595  (opens in a new tab)

How to fix?

Upgrade SLES:15.6 dlm-kmp-default to version 6.4.0-150600.23.73.1 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream dlm-kmp-default package and not the dlm-kmp-default package as distributed by SLES. See How to fix? for SLES:15.6 relevant fixed versions and status.

In the Linux kernel, the following vulnerability has been resolved:

xen: fix UAF in dmabuf_exp_from_pages()

[dma_buf_fd() fixes; no preferences regarding the tree it goes through - up to xen folks]

As soon as we'd inserted a file reference into descriptor table, another thread could close it. That's fine for the case when all we are doing is returning that descriptor to userland (it's a race, but it's a userland race and there's nothing the kernel can do about it). However, if we follow fd_install() with any kind of access to objects that would be destroyed on close (be it the struct file itself or anything destroyed by its ->release()), we have a UAF.

dma_buf_fd() is a combination of reserving a descriptor and fd_install(). gntdev dmabuf_exp_from_pages() calls it and then proceeds to access the objects destroyed on close - starting with gntdev_dmabuf itself.

Fix that by doing reserving descriptor before anything else and do fd_install() only when everything had been set up.

CVSS Base Scores

version 3.1