CVE-2026-89996
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.
Leer descripción completaMostrar menos
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:
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/
Detalles técnicos trazas, registros y código del informe original
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.CVSS
NVD no ha asignado puntuación CVSS a esta CVE (habitual desde el cambio de política de abril de 2026).
Probabilidad de explotación (EPSS)
- Probabilidad de explotación en los próximos 30 días: 0.21%
- Percentil entre todas las CVEs puntuadas: 10
- Fecha de la puntuación: 4/10/2026
EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).
Tecnologías afectadas (1)
⚠ Inferidas por IA a partir de la descripción — NVD aún no ha analizado esta CVE; no son CPE verificados.
Referencias
JSON original (NVD)
Mostrar
{
"id": "CVE-2026-89996",
"cveTags": [],
"metrics": {},
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "c02a81fba74fe3488ad6b08bfb5a1329005418f8",
"lessThan": "1bf6083a41f810d760c4dcd1b80c5194a92575aa",
"versionType": "git"
},
{
"status": "affected",
"version": "c02a81fba74fe3488ad6b08bfb5a1329005418f8",
"lessThan": "69d57dbadb27ffd5eef34fd184bab145500cdabc",
"versionType": "git"
},
{
"status": "affected",
"version": "c02a81fba74fe3488ad6b08bfb5a1329005418f8",
"lessThan": "0d4a5d218055db29b50cc07d3d73d27007c2a391",
"versionType": "git"
},
{
"status": "affected",
"version": "c02a81fba74fe3488ad6b08bfb5a1329005418f8",
"lessThan": "30d0aff2c65a277135cfd8ea28fa1ee75e0ea4e0",
"versionType": "git"
}
],
"programFiles": [
"drivers/dma-buf/dma-buf.c",
"drivers/dma-buf/dma-heap.c",
"include/linux/dma-buf.h"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "5.6"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "5.6",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "6.12.112",
"versionType": "semver",
"lessThanOrEqual": "6.12.*"
},
{
"status": "unaffected",
"version": "6.18.52",
"versionType": "semver",
"lessThanOrEqual": "6.18.*"
},
{
"status": "unaffected",
"version": "7.2.5",
"versionType": "semver",
"lessThanOrEqual": "7.2.*"
},
{
"status": "unaffected",
"version": "7.3-rc2",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"drivers/dma-buf/dma-buf.c",
"drivers/dma-buf/dma-heap.c",
"include/linux/dma-buf.h"
],
"defaultStatus": "affected"
}
]
}
],
"published": "2026-09-16T11:17:10.810",
"references": [
{
"url": "https://git.kernel.org/stable/c/0d4a5d218055db29b50cc07d3d73d27007c2a391",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/1bf6083a41f810d760c4dcd1b80c5194a92575aa",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/30d0aff2c65a277135cfd8ea28fa1ee75e0ea4e0",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/69d57dbadb27ffd5eef34fd184bab145500cdabc",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"vulnStatus": "Received",
"descriptions": [
{
"lang": "en",
"value": "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_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/"
}
],
"lastModified": "2026-10-03T11:17:45.290",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}