Skip to main content
VulnerabilityPublished Updated

CVE-2025-38722: Linux kernel · habanalabs: fix UAF in export_dmabuf()

Source GCVE Database

0
Compare
Authoritative record:CVE-2025-38722· High 7.8

Not known to be exploited · CVSS 7.8 High · fixed in d26058c2349d77d1ef179a2cc9752ca12004b6ff : patch Linux kernel soon.

Data as of 30 Oct 2026, 16:33 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.

Thin evidence

One scorer or none
CVSS scores by source
CNA (Linux)CVSS 3.17.8
Patch
Available – fixed in d26058c2349d77d1ef179a2cc9752ca12004b6ff, c07886761fd6251db6938d4e747002e3d150d231, 33927f3d0ecdcff06326d6e4edb6166aed42811c +3
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 4 Sep 2025

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 30 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ db1a8dd916aac986871f6b873a3aefad906f383a, < d26058c2349d77d1ef179a2cc9752ca12004b6ff
Fixed in
  • d26058c2349d77d1ef179a2cc9752ca12004b6ff
LinuxLinuxAffected
  • ≥ db1a8dd916aac986871f6b873a3aefad906f383a, < c07886761fd6251db6938d4e747002e3d150d231
Fixed in
  • c07886761fd6251db6938d4e747002e3d150d231
LinuxLinuxAffected
  • ≥ db1a8dd916aac986871f6b873a3aefad906f383a, < 33927f3d0ecdcff06326d6e4edb6166aed42811c
Fixed in
  • 33927f3d0ecdcff06326d6e4edb6166aed42811c
LinuxLinuxAffected
  • ≥ db1a8dd916aac986871f6b873a3aefad906f383a, < 55c232d7e0241f1d5120b595e7a9de24c75ed3d8
Fixed in
  • 55c232d7e0241f1d5120b595e7a9de24c75ed3d8
LinuxLinuxAffected
  • ≥ db1a8dd916aac986871f6b873a3aefad906f383a, < 40deceb38f9db759772d1c289c28fd2a543f57fc
Fixed in
  • 40deceb38f9db759772d1c289c28fd2a543f57fc
LinuxLinuxAffected
  • ≥ db1a8dd916aac986871f6b873a3aefad906f383a, < 5b0c23e9ec3e161a893d6ff9b4fad479e4539627
Fixed in
  • 5b0c23e9ec3e161a893d6ff9b4fad479e4539627

Description

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.

References

Community reviews

Loading reviews…