diff options
author | Al Viro <viro@zeniv.linux.org.uk> | 2025-07-12 06:02:31 +0100 |
---|---|---|
committer | Al Viro <viro@zeniv.linux.org.uk> | 2025-07-12 01:11:14 -0400 |
commit | 33927f3d0ecdcff06326d6e4edb6166aed42811c (patch) | |
tree | 7618cbf9a6868cd9f2d765f1f315434964f55a98 /arch/um/include/um_malloc.h | |
parent | d7b8f8e20813f0179d8ef519541a3527e7661d3a (diff) |
habanalabs: fix UAF in export_dmabuf()
As soon as we'd inserted a file reference into descriptor table, another
thread could close it. That's fine for the case when all we are doing is
returning that descriptor to userland (it's a race, but it's a userland
race and there's nothing the kernel can do about it). However, if we
follow fd_install() with any kind of access to objects that would be
destroyed on close (be it the struct file itself or anything destroyed
by its ->release()), we have a UAF.
dma_buf_fd() is a combination of reserving a descriptor and fd_install().
habanalabs export_dmabuf() calls it and then proceeds to access the
objects destroyed on close. In particular, it grabs an extra reference to
another struct file that will be dropped as part of ->release() for ours;
that "will be" is actually "might have already been".
Fix that by reserving descriptor before anything else and do fd_install()
only when everything had been set up. As a side benefit, we no longer
have the failure exit with file already created, but reference to
underlying file (as well as ->dmabuf_export_cnt, etc.) not grabbed yet;
unlike dma_buf_fd(), fd_install() can't fail.
Fixes: db1a8dd916aa ("habanalabs: add support for dma-buf exporter")
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'arch/um/include/um_malloc.h')
0 files changed, 0 insertions, 0 deletions