[PATCH] udmabuf: vastly increase the size limit per dmabuf

[PATCH] udmabuf: vastly increase the size limit per dmabuf

[Xaver Hugl]

Buffer sizes can get big very fast, and the previous limit of 64MB
is easily hit nowadays.
I hit this problem while working on better multi-gpu copies for KWin,
where on my 5120x1440 monitor with scaling applied, some apps ended
up using a resolution of 8192x2304, resulting in buffer sizes of
roughly 75MB.

As another reference, with merely 32 bits per pixel, buffers reach
- 33MB for 4k
- 133MB for 8k
- 530MB for 16k

With 64bpp, those sizes would be doubled, and even 4k would hit the
previous 64MB limit.

Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
Cc: stable@vger.kernel.org
---
 drivers/dma-buf/udmabuf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 2f94be1df525..8cbba7ddfa00 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -20,9 +20,9 @@ static int list_limit = 1024;
 module_param(list_limit, int, 0644);
 MODULE_PARM_DESC(list_limit, "udmabuf_create_list->count limit. Default is 1024.");
 
-static int size_limit_mb = 64;
+static int size_limit_mb = 1024;
 module_param(size_limit_mb, int, 0644);
-MODULE_PARM_DESC(size_limit_mb, "Max size of a dmabuf, in megabytes. Default is 64.");
+MODULE_PARM_DESC(size_limit_mb, "Max size of a dmabuf, in megabytes. Default is 1024.");
 
 struct udmabuf {
 	pgoff_t pagecount;
-- 
2.55.0

Re: [PATCH] udmabuf: vastly increase the size limit per dmabuf

[Xaver Hugl]

There's also the question if the limit is needed at all, the commit
that added it didn't explain why it was added in the first place.
Could we remove it entirely? I don't know if that's feasible for
backporting though, since it would remove a module parameter.

- Xaver

Re: [PATCH] udmabuf: vastly increase the size limit per dmabuf

[Robert Mader]

See 
https://lore.kernel.org/dri-devel/20260722110145.36641-1-robert.mader@collabora.com/ 
;)

On 03.08.26 16:41, Xaver Hugl wrote:
> Buffer sizes can get big very fast, and the previous limit of 64MB
> is easily hit nowadays.
> I hit this problem while working on better multi-gpu copies for KWin,
> where on my 5120x1440 monitor with scaling applied, some apps ended
> up using a resolution of 8192x2304, resulting in buffer sizes of
> roughly 75MB.
>
> As another reference, with merely 32 bits per pixel, buffers reach
> - 33MB for 4k
> - 133MB for 8k
> - 530MB for 16k
>
> With 64bpp, those sizes would be doubled, and even 4k would hit the
> previous 64MB limit.
>
> Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
> Cc: stable@vger.kernel.org
> ---
>   drivers/dma-buf/udmabuf.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> index 2f94be1df525..8cbba7ddfa00 100644
> --- a/drivers/dma-buf/udmabuf.c
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -20,9 +20,9 @@ static int list_limit = 1024;
>   module_param(list_limit, int, 0644);
>   MODULE_PARM_DESC(list_limit, "udmabuf_create_list->count limit. Default is 1024.");
>   
> -static int size_limit_mb = 64;
> +static int size_limit_mb = 1024;
>   module_param(size_limit_mb, int, 0644);
> -MODULE_PARM_DESC(size_limit_mb, "Max size of a dmabuf, in megabytes. Default is 64.");
> +MODULE_PARM_DESC(size_limit_mb, "Max size of a dmabuf, in megabytes. Default is 1024.");
>   
>   struct udmabuf {
>   	pgoff_t pagecount;

-- 
Robert Mader
Consultant Software Developer

Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718

Re: [PATCH] udmabuf: vastly increase the size limit per dmabuf

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Unprivileged users can exhaust system memory by pinning an unbounded amount of pages, bypassing RLIMIT_MEMLOCK limits.
- [High] On 32-bit systems, an integer overflow in `udmabuf_create` during the accumulation of `pgcnt` allows a local attacker to bypass the `size_limit_mb` check and cause a kernel heap buffer overflow.
--

--- Patch [1]: [PATCH] udmabuf: vastly increase the size limit per dmabuf ---
commit 35feed24a80e2f326fb9ba08e55d7ef8e97bae25
Author: Xaver Hugl <xaver.hugl@kde.org>
udmabuf: vastly increase the size limit per dmabuf

This commit increases the default size limit per dmabuf from 64MB to 1024MB.
This accommodates larger buffers used by high-resolution displays when scaling
is applied.

> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> index bced421c0d658..be2bcda0fb0f3 100644
> --- a/drivers/dma-buf/udmabuf.c
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -20,9 +20,9 @@ static int list_limit = 1024;
>  module_param(list_limit, int, 0644);
>  MODULE_PARM_DESC(list_limit, "udmabuf_create_list->count limit. Default is 1024.");
>  
> -static int size_limit_mb = 64;
> +static int size_limit_mb = 1024;

[Severity: High]
This is a pre-existing issue, but does increasing the default size limit to
1024MB make it easier for unprivileged users to exhaust system memory?

In drivers/dma-buf/udmabuf.c:udmabuf_create(), memory is pinned using
memfd_pin_folios() but it doesn't appear to call account_locked_vm() or check
against RLIMIT_MEMLOCK:

drivers/dma-buf/udmabuf.c:udmabuf_create() {
    ...
		ret = udmabuf_pin_folios(ubuf, memfd, list[i].offset,
					 list[i].size, folios);
    ...
}

Without a hard limit on the total number of dmabufs a user can create, an
unprivileged user with access to /dev/udmabuf might be able to repeatedly
allocate dmabufs up to the size_limit_mb per file descriptor and pin system
memory until the tmpfs limit or physical RAM is completely exhausted.

[Severity: High]
This isn't a bug introduced by this patch, but does the larger size limit make
it easier to hit an integer overflow on 32-bit systems?

In drivers/dma-buf/udmabuf.c:udmabuf_create(), pgcnt is accumulated using a
32-bit pgoff_t on 32-bit systems:

drivers/dma-buf/udmabuf.c:udmabuf_create() {
    ...
		subpgcnt = list[i].size >> PAGE_SHIFT;
		pgcnt += subpgcnt;
		if (pgcnt > pglimit)
			goto err_noinit;
    ...
}

By supplying up to list_limit (default 1024) items, an attacker could spread
2^32 pages across the items such that pgcnt wraps around to a small value,
bypassing the pglimit check.

init_udmabuf() then allocates an undersized ubuf->pages array. Later, when
udmabuf_pin_folios() successfully pins the large items, it iterates over the
actual requested size and can write out of bounds into the small heap array:

drivers/dma-buf/udmabuf.c:udmabuf_pin_folios() {
    ...
		for (; subpgoff < fsize; subpgoff += PAGE_SIZE) {
			ubuf->pages[upgcnt] = folio_page(folios[cur_folio],
						subpgoff >> PAGE_SHIFT);
			++upgcnt;
		}
    ...
}

Triggering this out-of-bounds write requires memfd_pin_folios() to
successfully pin the largest item (minimum ~16.7 GB spread across 1024 items).
Thus, it relies on the 32-bit system having enough physical RAM available
(e.g. via PAE) to not fail safely with -ENOMEM before reaching the vulnerable
write.

>  module_param(size_limit_mb, int, 0644);
> -MODULE_PARM_DESC(size_limit_mb, "Max size of a dmabuf, in megabytes. Default is 64.");
> +MODULE_PARM_DESC(size_limit_mb, "Max size of a dmabuf, in megabytes. Default is 1024.");
>  
>  struct udmabuf {
>  	pgoff_t pagecount;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260803144120.11524-1-xaver.hugl@kde.org?part=1

Re: [PATCH] udmabuf: vastly increase the size limit per dmabuf

[Xaver Hugl]

Oh, nice! I should've checked the list before making a patch :D

Could your commit also be backported to stable? I fear I'll need to
find ways to work around this or disable the relevant optimizations in
KWin on older kernels either way, but it would be great if that could
at least be a very temporary problem.

- Xaver

Re: [PATCH] udmabuf: vastly increase the size limit per dmabuf

[Robert Mader]

Hi,

Vivek (thanks!) just pulled the patch into drm-misc-next / 
for-linux-next so it should go into 7.3 \o/

On 03.08.26 17:04, Xaver Hugl wrote:
> Oh, nice! I should've checked the list before making a patch :D
>
> Could your commit also be backported to stable? I fear I'll need to
> find ways to work around this or disable the relevant optimizations in
> KWin on older kernels either way, but it would be great if that could
> at least be a very temporary problem.

I'm not sure how realistic that is / how the policies around such 
changes are - there shouldn't be any serious risk of regressions, but 
who knows.

OTOH there are several other options AFAICS:

1. affected distros could backport the patch or set a higher limit via 
kernel command line

2. kwin could try to check the size 
(`/sys/module/udmabuf/parameters/size_limit_mb`) and disallow the code 
path if the required buffer size exceeds it (or just have a fallback in 
place whenever allocation fails)

Arguably having a working fallback path were possible would be good 
style either way - would it be a big effort to do so in kwin?

Best regards

>
> - Xaver

-- 
Robert Mader
Consultant Software Developer

Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718

Re: [PATCH] udmabuf: vastly increase the size limit per dmabuf

[Xaver Hugl]

Am Di., 4. Aug. 2026 um 09:04 Uhr schrieb Robert Mader
<robert.mader@collabora.com>:
> 1. affected distros could backport the patch or set a higher limit via
> kernel command line
Yeah, I'll put it in our packaging recommendations for KWin.

> Arguably having a working fallback path were possible would be good
> style either way - would it be a big effort to do so in kwin?
For multi-gpu copies, it's not too bad, and I already implemented that
part. For software rendering it would be rather annoying, but it's
arguably a very unlikely edge case that would be terribly slow at
these resolutions either way.
So it'll probably be fine.

Thanks,
- Xaver