CVE-2025-38722: habanalabs: fix UAF in export_dmabuf()
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.
Security readout for executives and security teams
Plain-English summary
A local user could trigger a timing flaw in Linux's habanalabs driver, causing the kernel to use memory after it has been freed. This may threaten system confidentiality, integrity, and availability. The issue is high severity, but the supplied sources do not report active exploitation.
Executive priority
Prioritize shared Linux hosts exposing habanalabs devices to less-trusted users or workloads. Inventory affected systems promptly and apply distribution-provided fixed kernels. Systems without the driver or reachable functionality are less likely to be exposed, but this should be verified rather than assumed.
Technical view
The export_dmabuf() flow installed a file descriptor before completing access to related reference-counted objects. Another thread could close the descriptor, run release handling, and destroy those objects before subsequent accesses, producing a use-after-free. The stable fixes reserve the descriptor first, complete setup, then call fd_install(), which cannot fail.
Likely exposure
Exposure is limited to Linux systems running an affected kernel where the habanalabs driver and export_dmabuf() path are available. The CVSS vector requires local access and low privileges, with no user interaction. The supplied affected-version data is ambiguous, so distribution packages should be checked against the referenced fixes.
Exploitation context
The bundle marks this CVE as absent from KEV and provides no evidence of active exploitation or public weaponization. Exploitation requires a local, low-privileged context and a concurrency race in affected driver functionality. Practical reliability and resulting capabilities are not established by the supplied evidence.
Researcher notes
No CWE is supplied. The affected-version data lists discrete releases and repeats one commit hash without clear range semantics. Four stable fix commits are provided. Confirm applicability through kernel commit ancestry or distributor advisories. The sources establish the race and use-after-free, but not exploit reliability or demonstrated security outcomes.
Mitigation direction
Update to a distributor kernel containing the applicable stable fix referenced for this CVE.
Reboot into the updated kernel and verify the running version.
If updating is delayed, consult distributor guidance and limit untrusted local access to the affected driver.
Validation and detection
Identify running kernel versions where the habanalabs driver is enabled or loaded.
Confirm whether workloads can reach the driver's DMA-BUF export functionality.
Compare kernel source or distributor changelogs with the four referenced stable fixes.
After remediation, verify hosts booted the fixed kernel and the driver still operates correctly.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-38722 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
5Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.