linux-kernel - Re: [PATCH] dma-buf: acquire name lock before read/write dma

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5b7cdb6c-45f2-6b31-bfdd-5cc68a2fda5e@amd.com>
Date:   Fri, 8 Oct 2021 08:38:27 +0200
From:   Christian König <christian.koenig@....com>
To:     guangming.cao@...iatek.com, Sumit Semwal <sumit.semwal@...aro.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        "open list:DMA BUFFER SHARING FRAMEWORK" 
        <linux-media@...r.kernel.org>,
        "open list:DMA BUFFER SHARING FRAMEWORK" 
        <dri-devel@...ts.freedesktop.org>,
        "moderated list:DMA BUFFER SHARING FRAMEWORK" 
        <linaro-mm-sig@...ts.linaro.org>,
        open list <linux-kernel@...r.kernel.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-arm-kernel@...ts.infradead.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@...ts.infradead.org>
Cc:     wsd_upstream@...iatek.com
Subject: Re: [PATCH] dma-buf: acquire name lock before read/write dma_buf.name

Am 08.10.21 um 08:29 schrieb guangming.cao@...iatek.com:
> From: Guangming Cao <Guangming.Cao@...iatek.com>
>
> Because dma-buf.name can be freed in func: "dma_buf_set_name",
> so, we need to acquire lock first before we read/write dma_buf.name
> to prevent Use After Free(UAF) issue.
>
> Signed-off-by: Guangming Cao <Guangming.Cao@...iatek.com>
> ---
>   drivers/dma-buf/dma-buf.c | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 511fe0d217a0..aebb51b3ff52 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -80,7 +80,9 @@ static void dma_buf_release(struct dentry *dentry)
>   		dma_resv_fini(dmabuf->resv);
>   
>   	module_put(dmabuf->owner);
> +	spin_lock(&dmabuf->name_lock);
>   	kfree(dmabuf->name);
> +	spin_unlock(&dmabuf->name_lock);

That here is certainly a NAK. This is the release function if somebody 
is changing the name on a released DMA-buf we have much bigger problems.

>   	kfree(dmabuf);
>   }
>   
> @@ -1372,6 +1374,8 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused)
>   		if (ret)
>   			goto error_unlock;
>   
> +
> +		spin_lock(&dmabuf->name_lock);
>   		seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\t%08lu\t%s\n",
>   				buf_obj->size,
>   				buf_obj->file->f_flags, buf_obj->file->f_mode,
> @@ -1379,6 +1383,7 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused)
>   				buf_obj->exp_name,
>   				file_inode(buf_obj->file)->i_ino,
>   				buf_obj->name ?: "");
> +		spin_unlock(&dmabuf->name_lock);

Yeah, that part looks like a good idea to me as well.

Christian.

>   
>   		robj = buf_obj->resv;
>   		fence = dma_resv_excl_fence(robj);