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. */
/**
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.
/**
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.
/**
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.
/**
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
/**
linaro-mm-sig@lists.linaro.org
-
Christian König -
Christian König -
Lizhi Hou -
Mario Limonciello -
Max Zhen