GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel dma-heap: failed copy_to_user leaks an already-installed dma-buf fd for process lifetime

UnscoredCVE-2026-89996Kernel, userspace & hypervisorcurated

Impact

DMA_HEAP_IOCTL_ALLOC installed the file descriptor into the caller's fd table before copying the result back to userspace. If that final copy_to_user() fails - which a local process can force reliably by mprotect()ing the argument page read-only between the copy-in and copy-out - the fd and its underlying dma-buf reference stay alive and pinned for the life of the process while userspace never learns the number. Repeating the ioctl leaks one dma-buf per call, so a local user can pin DMA heap memory until the process exits, which on a shared node is a denial-of-service against other workloads on the same host. Exposure depends on whether /dev/dma_heap/* is present and reachable; a typical GPU compute node with no dma-heap devices exposed to tenants is not affected.

Who can reach it

Local unprivileged user with an open handle on a /dev/dma_heap/<name> device. No remote or network path; no privilege escalation, the gain is pinned memory.

What to do

Take the stable kernel fix that restructures the allocation path so get_unused_fd_flags() reserves the number and fd_install() happens last (commits linked in the record). Applying it means booting a patched kernel, so each node must be drained and rebooted; livepatch is unlikely to cover the restructured ioctl path. If dma-heap devices are not exposed to tenants on your nodes, this can wait for the next scheduled kernel roll.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.