CVE-2026-89996 json
dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds
published 2026-09-16 53 d ago modified 2026-10-30 9 d ago also EUVD-2026-80604
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.2%
- EPSS 0.2% chance of exploitation in 30 days, percentile 11%
- public exploits
- 0
- none known
Summary
In the Linux kernel, the following vulnerability has been resolved:
dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds
DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the underlying dma-buf reference) are already visible to other threads in the same process and are leaked for the lifetime of the process.
The obvious "close it on the failure path" fix is unsafe: once fd_install() has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file. This was pointed out by Christian König on v1 [1].
Restructure the allocation path so that fd_install() is the last, unfailable step of a successful ioctl:
1. heap->ops->allocate() creates the dma_buf. 2. get_unused_fd_flags() reserves an fd number in the caller's fd table without publishing it, so no other thread can observe it. 3. copy_to_user() delivers the fd number to userspace; on failure the fd is returned with put_unused_fd() and the dma_buf reference is dropped with dma_buf_put(), leaving no user- visible state behind. 4. dma_buf_fd_install() publishes the fd and emits the trace_dma_buf_fd tracepoint -- from here on the ioctl cannot fail.
A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4.
The failure at step 3 is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and only /dev/dma_heap/<name> remains open.
No UAPI or heap-driver interface change.
[1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/
Patch / fix
- Linux Linux 6.1.191, 6.6.160, 6.12.112, 6.18.52, 7.2.5, 7.3
- linux Debian 13 6.12.113-1
- linux Debian 14 7.2.6-1
- linux-6.12 Debian 12 6.12.113-1~deb12u1
debian advisories DEBIAN-CVE-2026-89996
- linux Ubuntu 26.04 LTS 7.0.0-42.42
- linux-aws Ubuntu 26.04 LTS 7.0.0-1016.17
- linux-gcp Ubuntu 26.04 LTS 7.0.0-1016.18
- linux-ibm Ubuntu 26.04 LTS 7.0.0-1017.17
- linux-riscv Ubuntu 26.04 LTS 7.0.0-42.42.1
- linux-oracle Ubuntu 26.04 LTS 7.0.0-1015.16
- linux-hwe-7.0 Ubuntu 24.04 LTS 7.0.0-42.42~24.04.1
- linux-oem-7.0 Ubuntu 26.04 LTS 7.0.0-1017.17
ubuntu advisories UBUNTU-CVE-2026-89996
Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0
- kernel-source openSUSE Tumbleweed 7.2.7-1.1
opensuse advisories openSUSE-SU-2026:11880-1
- kernel Azure Linux 3.0 6.6.161.1-1
azure linux advisories AZL-101688
Azure Linux vulnerability data, Copyright (c) Microsoft Corporation, from https://github.com/microsoft/AzureLinuxVulnerabilityData via OSV, under the MIT licence; changed: normalised to fixed package versions per release. MIT
- git.kernel.org/stable/c/1953ef8d11eb5870fe621259708a90900bead272 commit
- git.kernel.org/stable/c/ad61defb3e66ac0c598ad6f39b57f15784543d46 commit
- git.kernel.org/stable/c/1bf6083a41f810d760c4dcd1b80c5194a92575aa commit
- git.kernel.org/stable/c/69d57dbadb27ffd5eef34fd184bab145500cdabc commit
- git.kernel.org/stable/c/0d4a5d218055db29b50cc07d3d73d27007c2a391 commit
- git.kernel.org/stable/c/30d0aff2c65a277135cfd8ea28fa1ee75e0ea4e0 commit
Vendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2026-89996 updated cvss 5.5
kernel: dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds
-
Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more Red Hat Enterprise Linux 10 kernel Red Hat OpenShift Container Platform 4 openshift/ose-rhel-coreos-9 Red Hat OpenShift Container Platform 5 openshift/ose-rhel-coreos-9affected: no fix available “Fix deferred”
-
Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat OpenShift Container Platform 4 openshift/ose-rhel-coreos-8not affected: vulnerable code not present
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
Exploit prediction
0.21% chance of exploitation in the next 30 days, higher than 11% of all scored CVEs (FIRST EPSS, 2026-11-08).
Affected products
- Linux Linux
Classification
- Technology feeds
References
- git.kernel.org /stable/c/1953ef8d11eb5870fe621259708a90900bead272
- git.kernel.org /stable/c/ad61defb3e66ac0c598ad6f39b57f15784543d46
- git.kernel.org /stable/c/1bf6083a41f810d760c4dcd1b80c5194a92575aa
- git.kernel.org /stable/c/69d57dbadb27ffd5eef34fd184bab145500cdabc
- git.kernel.org /stable/c/0d4a5d218055db29b50cc07d3d73d27007c2a391
- git.kernel.org /stable/c/30d0aff2c65a277135cfd8ea28fa1ee75e0ea4e0
Sources
- CVE List CVE-2026-89996
- NVD CVE-2026-89996
Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.