CVE-2026-89996— dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds
Quick assessment
Affected
Linux Linux
Exploitation
No confirmed in-the-wild exploitation; assess based on exposure
Recommended action
Check the vendor advisory and references for a fixed version. If immediate upgrade is impossible, restrict exposure and increase monitoring.
在 Linux 内核中，已解决以下漏洞： dma-buf: dma-heap: 在 copy_to_user() 成功之前不要发布 fd 会分配一个 dma-buf，并在 将结果复制回用户空间之前，通过 -> 将 fd 安装到调用者的 fd 表中。如果最后的 失败，用户空间无法得知该 fd 的编号，但该 fd（及其底层的 dma-buf 引用）已经对同一进程内的其他线程可见，并会在整个进程生命周期内发生泄漏。 显而易见的“在失败路径上关闭它”的修复方式并不安全：一旦 执行完毕，另一个线程可能已经对该 fd 执行了
Possible ATT&CK Techniques 1 AI
T1562.008Affected Version Matrix 10
| Vendor | Product | Version Range | Status |
|---|---|---|---|
| Linux | Linux | c02a81fba74fe3488ad6b08bfb5a1329005418f8< 1bf6083a41f810d760c4dcd1b80c5194a92575aa |
affected |
c02a81fba74fe3488ad6b08bfb5a1329005418f8< 69d57dbadb27ffd5eef34fd184bab145500cdabc |
affected | ||
c02a81fba74fe3488ad6b08bfb5a1329005418f8< 0d4a5d218055db29b50cc07d3d73d27007c2a391 |
affected | ||
c02a81fba74fe3488ad6b08bfb5a1329005418f8< 30d0aff2c65a277135cfd8ea28fa1ee75e0ea4e0 |
affected | ||
5.6 |
affected | ||
< 5.6 |
unaffected | ||
6.12.112≤ 6.12.* |
unaffected | ||
6.18.52≤ 6.18.* |
unaffected | ||
| … +2 more rows | |||
Get alerts for future matching vulnerabilities
Log in to subscribe
I. Basic Information for CVE-2026-89996
Vulnerability Information
Have questions about the vulnerability? See if Shenlong's analysis helps!
View Shenlong Deep Dive ↗
Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.
Vulnerability Title
dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds
Source: CVE Program / CVE List V5
Vulnerability Description
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/
Source: CVE Program / CVE List V5
CVSS Information
N/A
Source: CVE Program / CVE List V5
Vulnerability Type
N/A
Source: CVE Program / CVE List V5
Affected Products
II. Public POCs for CVE-2026-89996
| # | POC Description | Source Link | Shenlong Link |
|---|
AI-Generated POC
Premium
No public POC found.
Login to generate AI POCIII. Intelligence Information for CVE-2026-89996
请登录查看更多情报信息。
Patches & Fixes for CVE-2026-89996 (1)
Other References for CVE-2026-89996 (3)
Same Patch Batch · Linux · 2026-09-16 · 276 CVEs total
| CVE-2026-90048 | 9.8 CRITICAL | fs/ntfs3: fix slab-out-of-bounds write in ni_create_attr_list() |
| CVE-2026-90012 | 9.8 CRITICAL | spi: Fix DMA mapping ownership on partial map failure |
| CVE-2026-89970 | 9.8 CRITICAL | nvmet-auth: Synchronize timeout work during SQ teardown |
| CVE-2026-89857 | 9.8 CRITICAL | scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject |
| CVE-2026-89969 | 9.8 CRITICAL | nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU |
| CVE-2026-89847 | 9.8 CRITICAL | scsi: qla2xxx: Avoid double completion in async IOCB timeout |
| CVE-2026-89972 | 9.8 CRITICAL | nvme: add missing SRCU grace period in error path |
| CVE-2026-89990 | 9.8 CRITICAL | ceph: lock mutex in ceph_mds_check_access() |
| CVE-2026-90036 | 9.8 CRITICAL | NFSD: Prevent client use-after-free during blocked-lock reaping |
| CVE-2026-90038 | 9.8 CRITICAL | NFSD: Prevent client use-after-free during export state revocation |
| CVE-2026-90037 | 9.8 CRITICAL | NFSD: Prevent client use-after-free during close_lru reaping |
| CVE-2026-89788 | 9.8 CRITICAL | ksmbd: fix tree connection use-after-free in smb2_tree_connect() |
| CVE-2026-89783 | 9.8 CRITICAL | xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full |
| CVE-2026-90042 | 9.8 CRITICAL | ceph: properly decrypt filenames in vmalloc() buffers |
| CVE-2026-89778 | 9.8 CRITICAL | isofs: fix out-of-bounds page array access on empty zisofs block |
| CVE-2026-89915 | 9.3 CRITICAL | KVM: arm64: Remove VM-wide VNCR mapping counter |
| CVE-2026-90049 | 9.3 CRITICAL | net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() |
| CVE-2026-89775 | 9.3 CRITICAL | KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation |
| CVE-2026-89916 | 9.3 CRITICAL | KVM: arm64: Make VNCR invalidation participate in MMU invalidation retry |
| CVE-2026-89930 | 9.3 CRITICAL | KVM: nVMX: Service local TLB flushes on failed nested VM-Enter |
Showing top 20 of 276 CVEs. View all on vendor page → →
IV. Related Vulnerabilities
Same product: Linux
-
CVE-2026-98385
sched/cache: Decouple sched_cache_group from mm to fix UAF -
CVE-2026-98384
bpf: Fix out-of-bounds read of sk_protocol in bpf_sock_destr -
CVE-2026-98383
bpf: Disallow bpf_skb_pull_data() for LWT_SEG6LOCAL -
CVE-2026-98382
bpf: Reject dev-bound-only programs on other devices -
CVE-2026-98381
veth: manage XDP program pointers during channel resize
Same vendor: Linux
-
CVE-2026-98385
sched/cache: Decouple sched_cache_group from mm to fix UAF -
CVE-2026-98384
bpf: Fix out-of-bounds read of sk_protocol in bpf_sock_destr -
CVE-2026-98383
bpf: Disallow bpf_skb_pull_data() for LWT_SEG6LOCAL -
CVE-2026-98382
bpf: Reject dev-bound-only programs on other devices -
CVE-2026-98381
veth: manage XDP program pointers during channel resize
V. Comments for CVE-2026-89996
No comments yet