aboutsummaryrefslogtreecommitdiffstats
path: root/tools/testing/selftests/filesystems/kernfs_test.c
diff options
context:
space:
mode:
authorAl Viro <[email protected]>2025-07-12 05:02:31 +0000
committerAl Viro <[email protected]>2025-07-12 05:11:14 +0000
commit33927f3d0ecdcff06326d6e4edb6166aed42811c (patch)
tree7618cbf9a6868cd9f2d765f1f315434964f55a98 /tools/testing/selftests/filesystems/kernfs_test.c
parentLinux 6.16-rc5 (diff)
downloadkernel-33927f3d0ecdcff06326d6e4edb6166aed42811c.tar.gz
kernel-33927f3d0ecdcff06326d6e4edb6166aed42811c.zip
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 <[email protected]>
Diffstat (limited to 'tools/testing/selftests/filesystems/kernfs_test.c')
0 files changed, 0 insertions, 0 deletions