CVE-2026-89996

Status: UPDATED  |  Advisory ID: CVE-2026-89996

Key Details

Affected Products, Subsystems & Sectors

What to Know

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/[email protected]/ (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References