In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
dma-buf: dma-heap: don’t publish fd before copy_to_user() succeeds<\/p>\n
DMA_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.<\/p>\n
The 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\u00f6nig on v1 [1].<\/p>\n
Restructure the allocation path so that fd_install() is the last,
\nunfailable step of a successful ioctl:<\/p>\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.<\/p>\n
A 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.<\/p>\n
The 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\/ remains open.<\/p>\n
No UAPI or heap-driver interface change.<\/p>\n
[1] https:\/\/lore.kernel.org\/dri-devel\/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com\/<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
dma-buf: dma-heap: don’t publish fd before copy_to_user() succeeds<\/p>\n
DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd int<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-24683","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/24683","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=24683"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=24683"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=24683"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}