dma-buf: fix UAF in dma_buf_fd() tracepoint
Once FD_ADD() returns, the fd is live in the file descriptor table
and a thread sharing that table can close() it before DMA_BUF_TRACE()
runs. The close drops the last reference, __fput() frees the dma_buf,
and the tracepoint then dereferences dmabuf to take dmabuf->name_lock
-- slab-use-after-free.
Split FD_ADD() back into get_unused_fd_flags() + fd_install() and
emit the tracepoint between them. While the fdtable slot is reserved
with a NULL file pointer, a racing close() returns -EBADF without
entering __fput(), so the dma_buf stays alive across the trace. Same
approach as commit 2d76319c4cbb ("dma-buf: fix UAF in dma_buf_put()
tracepoint").
This undoes the FD_ADD() conversion done in commit 34dfce523c90
("dma: convert dma_buf_fd() to FD_ADD()"); FD_ADD() has no place to
hook the tracepoint safely.
Metrics
Affected Vendors & Products
| Source | ID | Title |
|---|---|---|
Ubuntu USN |
USN-8593-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8603-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-8618-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8663-1 | Linux kernel (NVIDIA) vulnerabilities |
Ubuntu USN |
USN-8664-1 | Linux kernel (NVIDIA BaseOS) vulnerabilities |
Ubuntu USN |
USN-8728-1 | Linux kernel (GCP) vulnerabilities |
Ubuntu USN |
USN-8728-2 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-8728-3 | Linux kernel (Oracle) vulnerabilities |
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
Fri, 30 Oct 2026 14:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-416 | |
| CPEs | cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:7.1:rc3:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:7.1:rc4:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:7.1:rc5:*:*:*:*:*:* |
Sat, 25 Jul 2026 01:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-416 |
Wed, 22 Jul 2026 19:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-416 |
Wed, 22 Jul 2026 00:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-367 | |
| References |
| |
| Metrics |
threat_severity
|
threat_severity
|
Mon, 20 Jul 2026 14:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
cvssV3_1
|
Sun, 19 Jul 2026 15:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | In the Linux kernel, the following vulnerability has been resolved: dma-buf: fix UAF in dma_buf_fd() tracepoint Once FD_ADD() returns, the fd is live in the file descriptor table and a thread sharing that table can close() it before DMA_BUF_TRACE() runs. The close drops the last reference, __fput() frees the dma_buf, and the tracepoint then dereferences dmabuf to take dmabuf->name_lock -- slab-use-after-free. Split FD_ADD() back into get_unused_fd_flags() + fd_install() and emit the tracepoint between them. While the fdtable slot is reserved with a NULL file pointer, a racing close() returns -EBADF without entering __fput(), so the dma_buf stays alive across the trace. Same approach as commit 2d76319c4cbb ("dma-buf: fix UAF in dma_buf_put() tracepoint"). This undoes the FD_ADD() conversion done in commit 34dfce523c90 ("dma: convert dma_buf_fd() to FD_ADD()"); FD_ADD() has no place to hook the tracepoint safely. | |
| Title | dma-buf: fix UAF in dma_buf_fd() tracepoint | |
| First Time appeared |
Linux
Linux linux Kernel |
|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux
Linux linux Kernel |
|
| References |
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2026-08-05T12:37:04.026Z
Reserved: 2026-07-19T07:54:57.020Z
Link: CVE-2026-63910
No data.
Status : Analyzed
Published: 2026-07-19T16:17:08.857
Modified: 2026-10-30T14:29:37.863
Link: CVE-2026-63910
OpenCVE Enrichment
Updated: 2026-10-30T17:15:14Z
Ubuntu USN