{"id":"CVE-2026-89996","title":"In the Linux kernel, the following vulnerability has been resolved:\n\ndma-buf: dma-heap: don't publish fd before copy_to_user() succeeds\n\nDMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the\ncaller's fd table via dma_buf_f…","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndma-buf: dma-heap: don't publish fd before copy_to_user() succeeds\n\nDMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the\ncaller's fd table via dma_buf_f…","severity":"none","vendor":"Linux","product":"Linux","affected":["Linux >= c02a81fba74fe3488ad6b08bfb5a1329005418f8 < 69d57dbadb27ffd5eef34fd184bab145500cdabc","Linux >= c02a81fba74fe3488ad6b08bfb5a1329005418f8 < 0d4a5d218055db29b50cc07d3d73d27007c2a391","Linux >= c02a81fba74fe3488ad6b08bfb5a1329005418f8 < 30d0aff2c65a277135cfd8ea28fa1ee75e0ea4e0","Linux 5.6"],"published":"2026-09-16","updated":"2026-09-16","sourceUpdated":"2026-09-16T11:17:10.810","source":"NVD","sourceUrl":"https://nvd.nist.gov/vuln/detail/CVE-2026-89996","references":[{"url":"https://git.kernel.org/stable/c/0d4a5d218055db29b50cc07d3d73d27007c2a391","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/30d0aff2c65a277135cfd8ea28fa1ee75e0ea4e0","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/69d57dbadb27ffd5eef34fd184bab145500cdabc","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"}],"tags":["nvd","cve.org"],"ingestedAt":"2026-09-16T10:53:53.946Z","epss":0.00198,"epssPercentile":0.09861,"slug":"CVE-2026-89996","body":"## Overview\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndma-buf: dma-heap: don't publish fd before copy_to_user() succeeds\n\nDMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the\ncaller's fd table via dma_buf_fd() -> fd_install() before\ndma_heap_ioctl() copies the result back to userspace.  If the trailing\ncopy_to_user() fails, userspace never learns the fd number, but the\nfd (and the underlying dma-buf reference) are already visible to\nother threads in the same process and are leaked for the lifetime of\nthe process.\n\nThe obvious \"close it on the failure path\" fix is unsafe: once\nfd_install() has run, another thread can already dup() the fd, send\nit via SCM_RIGHTS, or close() it and let its number be reused, so a\nsubsequent close_fd() from the ioctl path can operate on an unrelated\nfile.  This was pointed out by Christian König on v1 [1].\n\nRestructure the allocation path so that fd_install() is the last,\nunfailable step of a successful ioctl:\n\n  1. heap->ops->allocate()      creates the dma_buf.\n  2. get_unused_fd_flags()      reserves an fd number in the caller's\n                                fd table without publishing it, so\n                                no other thread can observe it.\n  3. copy_to_user()             delivers the fd number to userspace;\n                                on failure the fd is returned with\n                                put_unused_fd() and the dma_buf\n                                reference is dropped with\n                                dma_buf_put(), leaving no user-\n                                visible state behind.\n  4. dma_buf_fd_install()       publishes the fd and emits the\n                                trace_dma_buf_fd tracepoint -- from\n                                here on the ioctl cannot fail.\n\nA new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap\nfd_install() together with the DMA_BUF_TRACE() call, preserving the\nexport tracing that dma_buf_fd() provides.  dma_heap_ioctl_allocate()\nis refactored to return the struct dma_buf * directly (returning\nERR_PTR on failure) so the caller holds the dmabuf reference across\nsteps 3 and 4.\n\nThe failure at step 3 is easily reachable from userspace: pass a\nstruct dma_heap_allocation_data that lives in a page whose protection\nis flipped to PROT_READ between copy_from_user() and copy_to_user()\n(e.g. via mprotect()).  Before this change each such ioctl leaks one\ndmabuf fd; after it, the fd table is unchanged on failure and only\n/dev/dma_heap/<name> remains open.\n\nNo UAPI or heap-driver interface change.\n\n[1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.","depth":"sunlit","depthScore":3,"depthScoreParts":{"impact":2.8,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}