linux-kernel - Re: [PATCH v5 2/3] dma-buf: add DMA_BUF_SET

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] [day] [month] [year] [list]

Message-ID: <156413022619.30723.12163288418173479775@skylake-alporthouse-com>
Date:   Fri, 26 Jul 2019 09:37:06 +0100
From:   Chris Wilson <chris@...is-wilson.co.uk>
To:     Chenbo Feng <fengc@...gle.com>, dri-devel@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org
Cc:     Sumit Semwal <sumit.semwal@...aro.org>, kernel-team@...roid.com
Subject: Re: [PATCH v5 2/3] dma-buf: add DMA_BUF_SET_NAME ioctls

Quoting Chenbo Feng (2019-06-13 23:34:07)
> From: Greg Hackmann <ghackmann@...gle.com>
> 
> This patch adds complimentary DMA_BUF_SET_NAME  ioctls, which lets
> userspace processes attach a free-form name to each buffer.
> 
> This information can be extremely helpful for tracking and accounting
> shared buffers.  For example, on Android, we know what each buffer will
> be used for at allocation time: GL, multimedia, camera, etc.  The
> userspace allocator can use DMA_BUF_SET_NAME to associate that
> information with the buffer, so we can later give developers a
> breakdown of how much memory they're allocating for graphics, camera,
> etc.

The name was never freed...
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d56993238501..0106b96da585 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -104,6 +104,8 @@ static int dma_buf_release(struct inode *inode, struct file *file)
        list_del(&dmabuf->list_node);
        mutex_unlock(&db_list.lock);

+       kfree(dmabuf->name);
+
        if (dmabuf->resv == (struct reservation_object *)&dmabuf[1])
                reservation_object_fini(dmabuf->resv);

This trusts that access to the name via the fs is serialised by the
refcount.

It would have been great if the inode would only be allocated for a
named dmabuf, but I expect that requires replacing struct file after it
is exposed (but maybe a struct file can be moved between fs?).
-Chris