habanalabs: fix UAF in export_dmabuf()
authorAl Viro <viro@zeniv.linux.org.uk>
Sat, 12 Jul 2025 05:02:31 +0000 (06:02 +0100)
committerAl Viro <viro@zeniv.linux.org.uk>
Sat, 12 Jul 2025 05:11:14 +0000 (01:11 -0400)
commit33927f3d0ecdcff06326d6e4edb6166aed42811c
tree7618cbf9a6868cd9f2d765f1f315434964f55a98
parentd7b8f8e20813f0179d8ef519541a3527e7661d3a
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>
drivers/accel/habanalabs/common/memory.c