Bug 2502439 (CVE-2026-63910) - CVE-2026-63910 kernel: dma-buf: fix UAF in dma_buf_fd() tracepoint
Summary: CVE-2026-63910 kernel: dma-buf: fix UAF in dma_buf_fd() tracepoint
Keywords:
Status: NEW
Alias: CVE-2026-63910
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-07-19 16:08 UTC by OSIDB Bzimport
Modified: 2026-07-21 15:56 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-07-19 16:08:11 UTC
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.

Comment 1 Mauro Matteo Cascella 2026-07-21 15:49:26 UTC
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026071945-CVE-2026-63910-d6b3@gregkh/T


Note You need to log in before you can comment on or make changes to this bug.