habanalabs: fix UAF in export_dmabuf()

Overview

In the Linux kernel, the following vulnerability has been resolved:

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.

Affected

• Linux >= db1a8dd916aac986871f6b873a3aefad906f383a < d26058c2349d77d1ef179a2cc9752ca12004b6ff
• Linux >= db1a8dd916aac986871f6b873a3aefad906f383a < c07886761fd6251db6938d4e747002e3d150d231
• Linux >= db1a8dd916aac986871f6b873a3aefad906f383a < 40deceb38f9db759772d1c289c28fd2a543f57fc
• Linux >= db1a8dd916aac986871f6b873a3aefad906f383a < 55c232d7e0241f1d5120b595e7a9de24c75ed3d8
• Linux >= db1a8dd916aac986871f6b873a3aefad906f383a < 33927f3d0ecdcff06326d6e4edb6166aed42811c
• Linux 5.16

Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.