summaryrefslogtreecommitdiff
path: root/lib/livepatch
diff options
context:
space:
mode:
authorAl Viro <viro@zeniv.linux.org.uk>2025-07-12 06:02:31 +0100
committerAl Viro <viro@zeniv.linux.org.uk>2025-07-12 01:11:14 -0400
commit33927f3d0ecdcff06326d6e4edb6166aed42811c (patch)
tree7618cbf9a6868cd9f2d765f1f315434964f55a98 /lib/livepatch
parentd7b8f8e20813f0179d8ef519541a3527e7661d3a (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 'lib/livepatch')
0 files changed, 0 insertions, 0 deletions