forked from Minki/linux
05cd84691e
It is observed 'use-after-free' on the dmabuf's file->f_inode with the
race between closing the dmabuf file and reading the dmabuf's debug
info.
Consider the below scenario where P1 is closing the dma_buf file
and P2 is reading the dma_buf's debug info in the system:
P1 P2
dma_buf_debug_show()
dma_buf_put()
__fput()
file->f_op->release()
dput()
....
dentry_unlink_inode()
iput(dentry->d_inode)
(where the inode is freed)
mutex_lock(&db_list.lock)
read 'dma_buf->file->f_inode'
(the same inode is freed by P1)
mutex_unlock(&db_list.lock)
dentry->d_op->d_release()-->
dma_buf_release()
.....
mutex_lock(&db_list.lock)
removes the dmabuf from the list
mutex_unlock(&db_list.lock)
In the above scenario, when dma_buf_put() is called on a dma_buf, it
first frees the dma_buf's file->f_inode(=dentry->d_inode) and then
removes this dma_buf from the system db_list. In between P2 traversing
the db_list tries to access this dma_buf's file->f_inode that was freed
by P1 which is a use-after-free case.
Since, __fput() calls f_op->release first and then later calls the
d_op->d_release, move the dma_buf's db_list removal from d_release() to
f_op->release(). This ensures that dma_buf's file->f_inode is not
accessed after it is released.
Cc: <stable@vger.kernel.org> # 5.4.x-
Fixes:
|
||
|---|---|---|
| .. | ||
| heaps | ||
| dma-buf.c | ||
| dma-fence-array.c | ||
| dma-fence-chain.c | ||
| dma-fence.c | ||
| dma-heap.c | ||
| dma-resv.c | ||
| Kconfig | ||
| Makefile | ||
| selftest.c | ||
| selftest.h | ||
| selftests.h | ||
| seqno-fence.c | ||
| st-dma-fence-chain.c | ||
| st-dma-fence.c | ||
| sw_sync.c | ||
| sync_debug.c | ||
| sync_debug.h | ||
| sync_file.c | ||
| sync_trace.h | ||
| udmabuf.c | ||