Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which happens if the dma_buf_release() is called while the userspace is accessing the dma_buf pseudo fs's dmabuffs_dname() in another process, and dma_buf_release() releases the dmabuf object when the last reference to the struct file goes away.
I discussed with Arnd Bergmann, and he suggested that rather than tying the dma_buf_release() to the file_operations' release(), we can tie it to the dentry_operations' d_release(), which will be called when the last ref to the dentry is removed.
The path exercised by __fput() calls f_op->release() first, and then calls dput, which eventually calls d_op->d_release().
In the 'normal' case, when no userspace access is happening via dma_buf pseudo fs, there should be exactly one fd, file, dentry and inode, so closing the fd will kill of everything right away.
In the presented case, the dentry's d_release() will be called only when the dentry's last ref is released.
Therefore, lets move dma_buf_release() from fops->release() to d_ops->d_release()
Many thanks to Arnd for his FS insights :)
[1]: https://lore.kernel.org/patchwork/patch/1238278/
Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls") Reported-by: syzbot+3643a18836bce555bff6@syzkaller.appspotmail.com Cc: stable@vger.kernel.org [5.3+] Cc: Arnd Bergmann arnd@arndb.de Reported-by: Charan Teja Reddy charante@codeaurora.org Reviewed-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Sumit Semwal sumit.semwal@linaro.org
--- v2: per Arnd: Moved dma_buf_release() above to avoid forward declaration; removed dentry_ops check. --- drivers/dma-buf/dma-buf.c | 54 ++++++++++++++++++--------------------- 1 file changed, 25 insertions(+), 29 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 01ce125f8e8d..412629601ad3 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -54,37 +54,11 @@ static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen) dentry->d_name.name, ret > 0 ? name : ""); }
-static const struct dentry_operations dma_buf_dentry_ops = { - .d_dname = dmabuffs_dname, -}; - -static struct vfsmount *dma_buf_mnt; - -static int dma_buf_fs_init_context(struct fs_context *fc) -{ - struct pseudo_fs_context *ctx; - - ctx = init_pseudo(fc, DMA_BUF_MAGIC); - if (!ctx) - return -ENOMEM; - ctx->dops = &dma_buf_dentry_ops; - return 0; -} - -static struct file_system_type dma_buf_fs_type = { - .name = "dmabuf", - .init_fs_context = dma_buf_fs_init_context, - .kill_sb = kill_anon_super, -}; - -static int dma_buf_release(struct inode *inode, struct file *file) +static void dma_buf_release(struct dentry *dentry) { struct dma_buf *dmabuf;
- if (!is_dma_buf_file(file)) - return -EINVAL; - - dmabuf = file->private_data; + dmabuf = dentry->d_fsdata;
BUG_ON(dmabuf->vmapping_counter);
@@ -110,9 +84,32 @@ static int dma_buf_release(struct inode *inode, struct file *file) module_put(dmabuf->owner); kfree(dmabuf->name); kfree(dmabuf); +} + +static const struct dentry_operations dma_buf_dentry_ops = { + .d_dname = dmabuffs_dname, + .d_release = dma_buf_release, +}; + +static struct vfsmount *dma_buf_mnt; + +static int dma_buf_fs_init_context(struct fs_context *fc) +{ + struct pseudo_fs_context *ctx; + + ctx = init_pseudo(fc, DMA_BUF_MAGIC); + if (!ctx) + return -ENOMEM; + ctx->dops = &dma_buf_dentry_ops; return 0; }
+static struct file_system_type dma_buf_fs_type = { + .name = "dmabuf", + .init_fs_context = dma_buf_fs_init_context, + .kill_sb = kill_anon_super, +}; + static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma) { struct dma_buf *dmabuf; @@ -412,7 +409,6 @@ static void dma_buf_show_fdinfo(struct seq_file *m, struct file *file) }
static const struct file_operations dma_buf_fops = { - .release = dma_buf_release, .mmap = dma_buf_mmap_internal, .llseek = dma_buf_llseek, .poll = dma_buf_poll,
Hello,
If there are no objections to this, I will plan to merge it soon.
Daniel, Chris, Chenbo?
On Thu, 11 Jun 2020 at 17:14, Sumit Semwal sumit.semwal@linaro.org wrote:
Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which happens if the dma_buf_release() is called while the userspace is accessing the dma_buf pseudo fs's dmabuffs_dname() in another process, and dma_buf_release() releases the dmabuf object when the last reference to the struct file goes away.
I discussed with Arnd Bergmann, and he suggested that rather than tying the dma_buf_release() to the file_operations' release(), we can tie it to the dentry_operations' d_release(), which will be called when the last ref to the dentry is removed.
The path exercised by __fput() calls f_op->release() first, and then calls dput, which eventually calls d_op->d_release().
In the 'normal' case, when no userspace access is happening via dma_buf pseudo fs, there should be exactly one fd, file, dentry and inode, so closing the fd will kill of everything right away.
In the presented case, the dentry's d_release() will be called only when the dentry's last ref is released.
Therefore, lets move dma_buf_release() from fops->release() to d_ops->d_release()
Many thanks to Arnd for his FS insights :)
Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls") Reported-by: syzbot+3643a18836bce555bff6@syzkaller.appspotmail.com Cc: stable@vger.kernel.org [5.3+] Cc: Arnd Bergmann arnd@arndb.de Reported-by: Charan Teja Reddy charante@codeaurora.org Reviewed-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Sumit Semwal sumit.semwal@linaro.org
v2: per Arnd: Moved dma_buf_release() above to avoid forward declaration; removed dentry_ops check.
drivers/dma-buf/dma-buf.c | 54 ++++++++++++++++++--------------------- 1 file changed, 25 insertions(+), 29 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 01ce125f8e8d..412629601ad3 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -54,37 +54,11 @@ static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen) dentry->d_name.name, ret > 0 ? name : ""); }
-static const struct dentry_operations dma_buf_dentry_ops = {
.d_dname = dmabuffs_dname,
-};
-static struct vfsmount *dma_buf_mnt;
-static int dma_buf_fs_init_context(struct fs_context *fc) -{
struct pseudo_fs_context *ctx;
ctx = init_pseudo(fc, DMA_BUF_MAGIC);
if (!ctx)
return -ENOMEM;
ctx->dops = &dma_buf_dentry_ops;
return 0;
-}
-static struct file_system_type dma_buf_fs_type = {
.name = "dmabuf",
.init_fs_context = dma_buf_fs_init_context,
.kill_sb = kill_anon_super,
-};
-static int dma_buf_release(struct inode *inode, struct file *file) +static void dma_buf_release(struct dentry *dentry) { struct dma_buf *dmabuf;
if (!is_dma_buf_file(file))
return -EINVAL;
dmabuf = file->private_data;
dmabuf = dentry->d_fsdata; BUG_ON(dmabuf->vmapping_counter);
@@ -110,9 +84,32 @@ static int dma_buf_release(struct inode *inode, struct file *file) module_put(dmabuf->owner); kfree(dmabuf->name); kfree(dmabuf); +}
+static const struct dentry_operations dma_buf_dentry_ops = {
.d_dname = dmabuffs_dname,
.d_release = dma_buf_release,
+};
+static struct vfsmount *dma_buf_mnt;
+static int dma_buf_fs_init_context(struct fs_context *fc) +{
struct pseudo_fs_context *ctx;
ctx = init_pseudo(fc, DMA_BUF_MAGIC);
if (!ctx)
return -ENOMEM;
ctx->dops = &dma_buf_dentry_ops; return 0;
}
+static struct file_system_type dma_buf_fs_type = {
.name = "dmabuf",
.init_fs_context = dma_buf_fs_init_context,
.kill_sb = kill_anon_super,
+};
static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma) { struct dma_buf *dmabuf; @@ -412,7 +409,6 @@ static void dma_buf_show_fdinfo(struct seq_file *m, struct file *file) }
static const struct file_operations dma_buf_fops = {
.release = dma_buf_release, .mmap = dma_buf_mmap_internal, .llseek = dma_buf_llseek, .poll = dma_buf_poll,
-- 2.27.0
Best, Sumit.
Quoting Sumit Semwal (2020-06-16 13:42:13)
Hello,
If there are no objections to this, I will plan to merge it soon.
I was going to suggest running it against our CI, but that's unavailable at the moment.
There's a particularly nasty BUG_ON() in dma_buf_release that we hit irregularly, that this might help with. -Chris
Hi Chris,
On Tue, 16 Jun 2020 at 18:20, Chris Wilson chris@chris-wilson.co.uk wrote:
Quoting Sumit Semwal (2020-06-16 13:42:13)
Hello,
If there are no objections to this, I will plan to merge it soon.
I was going to suggest running it against our CI, but that's unavailable at the moment.
There's a particularly nasty BUG_ON() in dma_buf_release that we hit irregularly, that this might help with.
Thanks for your reply; if the CI is going to be available in a couple of days, we could wait - it'd be definitely good to see a bug being splattered out!
-Chris
Best, Sumit.
Thanks Sumit for the fix.
On 6/11/2020 5:14 PM, Sumit Semwal wrote:
Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which happens if the dma_buf_release() is called while the userspace is accessing the dma_buf pseudo fs's dmabuffs_dname() in another process, and dma_buf_release() releases the dmabuf object when the last reference to the struct file goes away.
I discussed with Arnd Bergmann, and he suggested that rather than tying the dma_buf_release() to the file_operations' release(), we can tie it to the dentry_operations' d_release(), which will be called when the last ref to the dentry is removed.
The path exercised by __fput() calls f_op->release() first, and then calls dput, which eventually calls d_op->d_release().
In the 'normal' case, when no userspace access is happening via dma_buf pseudo fs, there should be exactly one fd, file, dentry and inode, so closing the fd will kill of everything right away.
In the presented case, the dentry's d_release() will be called only when the dentry's last ref is released.
Therefore, lets move dma_buf_release() from fops->release() to d_ops->d_release()
Many thanks to Arnd for his FS insights :)
Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls") Reported-by: syzbot+3643a18836bce555bff6@syzkaller.appspotmail.com Cc: stable@vger.kernel.org [5.3+] Cc: Arnd Bergmann arnd@arndb.de Reported-by: Charan Teja Reddy charante@codeaurora.org Reviewed-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Sumit Semwal sumit.semwal@linaro.org
Tested this patch for Android running on Snapdragon hardware and see no issues. Tested-by: Charan Teja Reddy charante@codeaurora.org
v2: per Arnd: Moved dma_buf_release() above to avoid forward declaration; removed dentry_ops check.
drivers/dma-buf/dma-buf.c | 54 ++++++++++++++++++--------------------- 1 file changed, 25 insertions(+), 29 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 01ce125f8e8d..412629601ad3 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -54,37 +54,11 @@ static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen) dentry->d_name.name, ret > 0 ? name : ""); } -static const struct dentry_operations dma_buf_dentry_ops = {
- .d_dname = dmabuffs_dname,
-};
-static struct vfsmount *dma_buf_mnt;
-static int dma_buf_fs_init_context(struct fs_context *fc) -{
- struct pseudo_fs_context *ctx;
- ctx = init_pseudo(fc, DMA_BUF_MAGIC);
- if (!ctx)
return -ENOMEM;
- ctx->dops = &dma_buf_dentry_ops;
- return 0;
-}
-static struct file_system_type dma_buf_fs_type = {
- .name = "dmabuf",
- .init_fs_context = dma_buf_fs_init_context,
- .kill_sb = kill_anon_super,
-};
-static int dma_buf_release(struct inode *inode, struct file *file) +static void dma_buf_release(struct dentry *dentry) { struct dma_buf *dmabuf;
- if (!is_dma_buf_file(file))
return -EINVAL;
- dmabuf = file->private_data;
- dmabuf = dentry->d_fsdata;
BUG_ON(dmabuf->vmapping_counter); @@ -110,9 +84,32 @@ static int dma_buf_release(struct inode *inode, struct file *file) module_put(dmabuf->owner); kfree(dmabuf->name); kfree(dmabuf); +}
+static const struct dentry_operations dma_buf_dentry_ops = {
- .d_dname = dmabuffs_dname,
- .d_release = dma_buf_release,
+};
+static struct vfsmount *dma_buf_mnt;
+static int dma_buf_fs_init_context(struct fs_context *fc) +{
- struct pseudo_fs_context *ctx;
- ctx = init_pseudo(fc, DMA_BUF_MAGIC);
- if (!ctx)
return -ENOMEM;
- ctx->dops = &dma_buf_dentry_ops; return 0;
} +static struct file_system_type dma_buf_fs_type = {
- .name = "dmabuf",
- .init_fs_context = dma_buf_fs_init_context,
- .kill_sb = kill_anon_super,
+};
static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma) { struct dma_buf *dmabuf; @@ -412,7 +409,6 @@ static void dma_buf_show_fdinfo(struct seq_file *m, struct file *file) } static const struct file_operations dma_buf_fops = {
- .release = dma_buf_release, .mmap = dma_buf_mmap_internal, .llseek = dma_buf_llseek, .poll = dma_buf_poll,
Hello Charan,
On Tue, 16 Jun 2020 at 19:13, Charan Teja Kalla charante@codeaurora.org wrote:
Thanks Sumit for the fix.
On 6/11/2020 5:14 PM, Sumit Semwal wrote:
Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which happens if the dma_buf_release() is called while the userspace is accessing the dma_buf pseudo fs's dmabuffs_dname() in another process, and dma_buf_release() releases the dmabuf object when the last reference to the struct file goes away.
I discussed with Arnd Bergmann, and he suggested that rather than tying the dma_buf_release() to the file_operations' release(), we can tie it to the dentry_operations' d_release(), which will be called when the last ref to the dentry is removed.
The path exercised by __fput() calls f_op->release() first, and then calls dput, which eventually calls d_op->d_release().
In the 'normal' case, when no userspace access is happening via dma_buf pseudo fs, there should be exactly one fd, file, dentry and inode, so closing the fd will kill of everything right away.
In the presented case, the dentry's d_release() will be called only when the dentry's last ref is released.
Therefore, lets move dma_buf_release() from fops->release() to d_ops->d_release()
Many thanks to Arnd for his FS insights :)
Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls") Reported-by: syzbot+3643a18836bce555bff6@syzkaller.appspotmail.com Cc: stable@vger.kernel.org [5.3+] Cc: Arnd Bergmann arnd@arndb.de Reported-by: Charan Teja Reddy charante@codeaurora.org Reviewed-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Sumit Semwal sumit.semwal@linaro.org
Tested this patch for Android running on Snapdragon hardware and see no issues. Tested-by: Charan Teja Reddy charante@codeaurora.org
Thanks for your tested-by, appreciate it!
Chris, any luck with your CI to test if this also helps your dma_buf_release() bug that you guys have seen?
If you've not been able to test, and there are no more objections by EOD today, I will merge this to the drm-misc-fixes branch.
v2: per Arnd: Moved dma_buf_release() above to avoid forward declaration; removed dentry_ops check.
<snip> Best, Sumit.
linaro-mm-sig@lists.linaro.org