[PATCH] dma-buf: explicitely forbid exposing pages from get_user_pages()

[PATCH] dma-buf: explicitely forbid exposing pages from get_user_pages()

[Christian König]

We recently had another incident where two drivers put pages they got from
get_user_pages() into a DMA-buf and cause quite a number of problems.

Explicitely document that this is not something exporters can do.

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 drivers/dma-buf/dma-buf.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 71f37544a5c6..aa5af4f439c2 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -685,6 +685,14 @@ static struct file *dma_buf_getfile(size_t size, int flags)
  *
  * For the detailed semantics exporters are expected to implement see
  * &dma_buf_ops.
+ *
+ * It is explicitely forbidden for exporters to expose buffers they don't "own"
+ * as DMA-buf. This includes pages acquired by get_user_pages() or other import
+ * mechanism. Not following this rule can create numerous security problems.
+ *
+ * It is also strongly discouraged to expose the same backing store through
+ * multiple DMA-bufs at the same time. This eventually creates aliasing and
+ * cache coherency problems which are extremely hard to debug and fix.
  */
 
 /**
-- 
2.43.0

Re: [PATCH] dma-buf: explicitely forbid exposing pages from get_user_pages()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Misspelling of the word 'explicitly' as 'explicitely' in both the commit message and the newly added source code comments. Additionally, 'import mechanism' is slightly awkward grammatically and would read better as 'import mechanisms'.
--

commit d403e672a4ce196480792c8a6cdd1c4a2ffcf542
Author: Christian König <ckoenig.leichtzumerken@gmail.com>

dma-buf: explicitely forbid exposing pages from get_user_pages()

This commit documents that DMA-buf exporters are forbidden from exposing
pages they do not own, such as those acquired by get_user_pages(). It also
discourages exposing the same backing store through multiple DMA-bufs to
avoid aliasing and cache coherency problems.

> dma-buf: explicitely forbid exposing pages from get_user_pages()

[Severity: Low]
This isn't a bug, but there is a typo (explicitely) in the subject line.

> Explicitely document that this is not something exporters can do.

[Severity: Low]
This isn't a bug, but there is a typo (Explicitely) in the commit message.

> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index d504c636dc294..b2efc3085e6d6 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -685,6 +685,14 @@ static struct file *dma_buf_getfile(size_t size, int flags)
>   *
>   * For the detailed semantics exporters are expected to implement see
>   * &dma_buf_ops.
> + *
> + * It is explicitely forbidden for exporters to expose buffers they don't "own"
> + * as DMA-buf. This includes pages acquired by get_user_pages() or other import
> + * mechanism. Not following this rule can create numerous security problems.

[Severity: Low]
This isn't a bug, but there is a typo (explicitely) in the new comment.
Additionally, would it read better to use the plural "mechanisms" here
instead of "mechanism"?

> + *
> + * It is also strongly discouraged to expose the same backing store through
> + * multiple DMA-bufs at the same time. This eventually creates aliasing and
> + * cache coherency problems which are extremely hard to debug and fix.
>   */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630080112.1117341-1-christian.koenig@amd.com?part=1

Re: [PATCH] dma-buf: explicitely forbid exposing pages from get_user_pages()

[Mario Limonciello]

On 6/30/26 03:01, Christian König wrote:
> We recently had another incident where two drivers put pages they got from
> get_user_pages() into a DMA-buf and cause quite a number of problems.
> 
> Explicitely document that this is not something exporters can do.

I think it would be a good idea to send this up to 
https://github.com/masoncl/review-prompts/blob/main/kernel/subsystem/drm.md 
as well.

That's what Sashiko uses and it will help flag this in case it happens 
in future.

> 
> Signed-off-by: Christian König <christian.koenig@amd.com>
> ---
>   drivers/dma-buf/dma-buf.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 71f37544a5c6..aa5af4f439c2 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -685,6 +685,14 @@ static struct file *dma_buf_getfile(size_t size, int flags)
>    *
>    * For the detailed semantics exporters are expected to implement see
>    * &dma_buf_ops.
> + *
> + * It is explicitely forbidden for exporters to expose buffers they don't "own"
> + * as DMA-buf. This includes pages acquired by get_user_pages() or other import
> + * mechanism. Not following this rule can create numerous security problems.
> + *
> + * It is also strongly discouraged to expose the same backing store through
> + * multiple DMA-bufs at the same time. This eventually creates aliasing and
> + * cache coherency problems which are extremely hard to debug and fix.
>    */
>   
>   /**

Re: [PATCH] dma-buf: explicitely forbid exposing pages from get_user_pages()

[Christian König]

Gentle ping.

Apart from the spelling mistakes Sashiko already pointed out, any comments on that?

Regards,
Christian.

On 6/30/26 10:01, Christian König wrote:
> We recently had another incident where two drivers put pages they got from
> get_user_pages() into a DMA-buf and cause quite a number of problems.
> 
> Explicitely document that this is not something exporters can do.
> 
> Signed-off-by: Christian König <christian.koenig@amd.com>
> ---
>  drivers/dma-buf/dma-buf.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 71f37544a5c6..aa5af4f439c2 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -685,6 +685,14 @@ static struct file *dma_buf_getfile(size_t size, int flags)
>   *
>   * For the detailed semantics exporters are expected to implement see
>   * &dma_buf_ops.
> + *
> + * It is explicitely forbidden for exporters to expose buffers they don't "own"
> + * as DMA-buf. This includes pages acquired by get_user_pages() or other import
> + * mechanism. Not following this rule can create numerous security problems.
> + *
> + * It is also strongly discouraged to expose the same backing store through
> + * multiple DMA-bufs at the same time. This eventually creates aliasing and
> + * cache coherency problems which are extremely hard to debug and fix.
>   */
>  
>  /**

Re: [PATCH] dma-buf: explicitely forbid exposing pages from get_user_pages()

[Max Zhen]

On 6/30/2026 Tue 01:01, Christian König wrote:
> We recently had another incident where two drivers put pages they got from
> get_user_pages() into a DMA-buf and cause quite a number of problems.
> 
> Explicitely document that this is not something exporters can do.
> 
> Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Max Zhen <max.zhen@amd.com>
> ---
>   drivers/dma-buf/dma-buf.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 71f37544a5c6..aa5af4f439c2 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -685,6 +685,14 @@ static struct file *dma_buf_getfile(size_t size, int flags)
>    *
>    * For the detailed semantics exporters are expected to implement see
>    * &dma_buf_ops.
> + *
> + * It is explicitely forbidden for exporters to expose buffers they don't "own"
> + * as DMA-buf. This includes pages acquired by get_user_pages() or other import
> + * mechanism. Not following this rule can create numerous security problems.
> + *
> + * It is also strongly discouraged to expose the same backing store through
> + * multiple DMA-bufs at the same time. This eventually creates aliasing and
> + * cache coherency problems which are extremely hard to debug and fix.
>    */
>   
>   /**

Re: [PATCH] dma-buf: explicitely forbid exposing pages from get_user_pages()

[Lizhi Hou]

On 6/30/26 01:01, Christian König wrote:
> We recently had another incident where two drivers put pages they got from
> get_user_pages() into a DMA-buf and cause quite a number of problems.
>
> Explicitely document that this is not something exporters can do.
>
> Signed-off-by: Christian König <christian.koenig@amd.com>
> ---
>   drivers/dma-buf/dma-buf.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 71f37544a5c6..aa5af4f439c2 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -685,6 +685,14 @@ static struct file *dma_buf_getfile(size_t size, int flags)
>    *
>    * For the detailed semantics exporters are expected to implement see
>    * &dma_buf_ops.
> + *
> + * It is explicitely forbidden for exporters to expose buffers they don't "own"
> + * as DMA-buf. This includes pages acquired by get_user_pages() or other import
> + * mechanism. Not following this rule can create numerous security problems.
> + *
> + * It is also strongly discouraged to expose the same backing store through
> + * multiple DMA-bufs at the same time. This eventually creates aliasing and
> + * cache coherency problems which are extremely hard to debug and fix.
>    */
Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
>   
>   /**