Use After Free Affecting kernel-64kb-devel package, versions <6.12.0-160000.6.1


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.02% (4th 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 Learn

Learn about Use After Free vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-SLES1600-KERNEL64KBDEVEL-13938543
  • published13 Nov 2025
  • disclosed6 Nov 2025

Introduced: 6 Nov 2025

CVE-2025-38722  (opens in a new tab)
CWE-416  (opens in a new tab)

How to fix?

Upgrade SLES:16.0.0 kernel-64kb-devel to version 6.12.0-160000.6.1 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-64kb-devel package and not the kernel-64kb-devel package as distributed by SLES. See How to fix? for SLES:16.0.0 relevant fixed versions and status.

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

habanalabs: fix UAF in export_dmabuf()

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(). habanalabs export_dmabuf() calls it and then proceeds to access the objects destroyed on close. In particular, it grabs an extra reference to another struct file that will be dropped as part of ->release() for ours; that "will be" is actually "might have already been".

Fix that by reserving descriptor before anything else and do fd_install() only when everything had been set up. As a side benefit, we no longer have the failure exit with file already created, but reference to underlying file (as well as ->dmabuf_export_cnt, etc.) not grabbed yet; unlike dma_buf_fd(), fd_install() can't fail.

CVSS Base Scores

version 3.1