| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <8424b2ac-3ea6-6e5b-b99c-951a569f493d@codeaurora.org>
Date: Wed, 6 May 2020 14:00:10 +0530
From: Charan Teja Kalla <charante@...eaurora.org>
To: Greg KH <gregkh@...uxfoundation.org>,
dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org,
linux-kernel@...r.kernel.org
Cc: vinmenon@...eaurora.org, sumit.semwal@...aro.org,
ghackmann@...gle.com, fengc@...gle.com, linux-media@...r.kernel.org
Subject: Re: [PATCH] dma-buf: fix use-after-free in dmabuffs_dname
Thank you Greg for the reply.
On 5/5/2020 3:38 PM, Greg KH wrote:
> On Tue, Apr 28, 2020 at 01:24:02PM +0530, Charan Teja Reddy wrote:
>> The following race occurs while accessing the dmabuf object exported as
>> file:
>> P1 P2
>> dma_buf_release() dmabuffs_dname()
>> [say lsof reading /proc/<P1 pid>/fd/<num>]
>>
>> read dmabuf stored in dentry->fsdata
>> Free the dmabuf object
>> Start accessing the dmabuf structure
>>
>> In the above description, the dmabuf object freed in P1 is being
>> accessed from P2 which is resulting into the use-after-free. Below is
>> the dump stack reported.
>>
>> Call Trace:
>> kasan_report+0x12/0x20
>> __asan_report_load8_noabort+0x14/0x20
>> dmabuffs_dname+0x4f4/0x560
>> tomoyo_realpath_from_path+0x165/0x660
>> tomoyo_get_realpath
>> tomoyo_check_open_permission+0x2a3/0x3e0
>> tomoyo_file_open
>> tomoyo_file_open+0xa9/0xd0
>> security_file_open+0x71/0x300
>> do_dentry_open+0x37a/0x1380
>> vfs_open+0xa0/0xd0
>> path_openat+0x12ee/0x3490
>> do_filp_open+0x192/0x260
>> do_sys_openat2+0x5eb/0x7e0
>> do_sys_open+0xf2/0x180
>>
>> Fixes: bb2bb90 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
> Nit, please read the documentation for how to do a Fixes: line properly,
> you need more digits:
> Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
Will update the patch
>> Reported-by:syzbot+3643a18836bce555bff6@...kaller.appspotmail.com
>> Signed-off-by: Charan Teja Reddy<charante@...eaurora.org>
> Also, any reason you didn't include the other mailing lists that
> get_maintainer.pl said to?
Really sorry for not sending to complete list. Added now.
> And finally, no cc: stable in the s-o-b area for an issue that needs to
> be backported to older kernels?
Will update the patch.
>
>> ---
>> drivers/dma-buf/dma-buf.c | 25 +++++++++++++++++++++++--
>> include/linux/dma-buf.h | 1 +
>> 2 files changed, 24 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 570c923..069d8f78 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -25,6 +25,7 @@
>> #include <linux/mm.h>
>> #include <linux/mount.h>
>> #include <linux/pseudo_fs.h>
>> +#include <linux/dcache.h>
>>
>> #include <uapi/linux/dma-buf.h>
>> #include <uapi/linux/magic.h>
>> @@ -38,18 +39,34 @@ struct dma_buf_list {
>>
>> static struct dma_buf_list db_list;
>>
>> +static void dmabuf_dent_put(struct dma_buf *dmabuf)
>> +{
>> + if (atomic_dec_and_test(&dmabuf->dent_count)) {
>> + kfree(dmabuf->name);
>> + kfree(dmabuf);
>> + }
> Why not just use a kref instead of an open-coded atomic value?
Kref approach looks cleaner. will update the patch accordingly.
>> +}
>> +
>> static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen)
>> {
>> struct dma_buf *dmabuf;
>> char name[DMA_BUF_NAME_LEN];
>> size_t ret = 0;
>>
>> + spin_lock(&dentry->d_lock);
>> dmabuf = dentry->d_fsdata;
>> + if (!dmabuf || !atomic_add_unless(&dmabuf->dent_count, 1, 0)) {
>> + spin_unlock(&dentry->d_lock);
>> + goto out;
> How can dmabuf not be valid here?
>
> And isn't there already a usecount for the buffer?
dmabuf exported as file simply relies on that file's refcount, thus
fput() releases the dmabuf.
We are storing the dmabuf in the dentry->d_fsdata but there is no
binding between the dentry and the dmabuf. So, flow will be like
1) P1 calls fput(dmabuf_fd)
2) P2 trying to access the file information of P1.
Eg: lsof command trying to list out the dmabuf_fd information using
/proc/<P1 pid>/fd/dmabuf_fd
3) P1 calls the file->f_op->release(dmabuf_fd_file)(ends up in calling
dma_buf_release()), thus frees up the dmabuf buffer.
4) P2 access the dmabuf stored in the dentry->d_fsdata which was freed
in step 3.
So we need to have some refcount mechanism to avoid the use-after-free
in step 4.
>> + }
>> + spin_unlock(&dentry->d_lock);
>> dma_resv_lock(dmabuf->resv, NULL);
>> if (dmabuf->name)
>> ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN);
>> dma_resv_unlock(dmabuf->resv);
>> + dmabuf_dent_put(dmabuf);
>>
>> +out:
>> return dynamic_dname(dentry, buffer, buflen, "/%s:%s",
>> dentry->d_name.name, ret > 0 ? name : "");
>> }
>> @@ -80,12 +97,16 @@ static int dma_buf_fs_init_context(struct fs_context *fc)
>> static int dma_buf_release(struct inode *inode, struct file *file)
>> {
>> struct dma_buf *dmabuf;
>> + struct dentry *dentry = file->f_path.dentry;
>>
>> if (!is_dma_buf_file(file))
>> return -EINVAL;
>>
>> dmabuf = file->private_data;
>>
>> + spin_lock(&dentry->d_lock);
>> + dentry->d_fsdata = NULL;
>> + spin_unlock(&dentry->d_lock);
>> BUG_ON(dmabuf->vmapping_counter);
>>
>> /*
>> @@ -108,8 +129,7 @@ static int dma_buf_release(struct inode *inode, struct file *file)
>> dma_resv_fini(dmabuf->resv);
>>
>> module_put(dmabuf->owner);
>> - kfree(dmabuf->name);
>> - kfree(dmabuf);
>> + dmabuf_dent_put(dmabuf);
>> return 0;
>> }
>>
>> @@ -548,6 +568,7 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
>> init_waitqueue_head(&dmabuf->poll);
>> dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll;
>> dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
>> + atomic_set(&dmabuf->dent_count, 1);
>>
>> if (!resv) {
>> resv = (struct dma_resv *)&dmabuf[1];
>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>> index 82e0a4a..a259042 100644
>> --- a/include/linux/dma-buf.h
>> +++ b/include/linux/dma-buf.h
>> @@ -315,6 +315,7 @@ struct dma_buf {
>> struct list_head list_node;
>> void *priv;
>> struct dma_resv *resv;
>> + atomic_t dent_count;
> Isn't there other usage counters here that can support this? Adding
> another one feels wrong as now we have multiple use counts, right?
I couldn't see any refcount exist and couldn't find the need either,
earlier.
But the change bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
requires to have one.
> thanks,
>
> greg k-h
Powered by blists - more mailing lists