[PATCH] vmalloc: fix buffer overflow in vrealloc_node_align()

[Marco Elver]

Commit 4c5d3365882d ("mm/vmalloc: allow to set node and align in
vrealloc") added the ability to force a new allocation if the current
pointer is on the wrong NUMA node, or if an alignment constraint is not
met, even if the user is shrinking the allocation.

On this path (need_realloc), the code allocates a new object of 'size'
bytes and then memcpy()s 'old_size' bytes into it. If the request is to
shrink the object (size < old_size), this results in an out-of-bounds
write on the new buffer.

Fix this by bounding the copy length by the new allocation size.

Fixes: 4c5d3365882d ("mm/vmalloc: allow to set node and align in vrealloc")
Cc: <sta...@vger.kernel.org>
Reported-by: Harry Yoo (Oracle) <ha...@kernel.org>
Signed-off-by: Marco Elver <el...@google.com>
---
mm/vmalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 61caa55a4402..8b1124158f54 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -4361,7 +4361,7 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align
return NULL;

if (p) {
- memcpy(n, p, old_size);
+ memcpy(n, p, min(size, old_size));
vfree(p);
}

--
2.54.0.rc1.513.gad8abe7a5a-goog

[Uladzislau Rezki]

Agree with a problem described in commit message:

Reviewed-by: Uladzislau Rezki (Sony) <ure...@gmail.com>

Thank you for fixing it!

--
Uladzislau Rezki

[Vlastimil Babka (SUSE)]

On 4/20/26 13:47, Marco Elver wrote:
> Commit 4c5d3365882d ("mm/vmalloc: allow to set node and align in
> vrealloc") added the ability to force a new allocation if the current
> pointer is on the wrong NUMA node, or if an alignment constraint is not
> met, even if the user is shrinking the allocation.
>
> On this path (need_realloc), the code allocates a new object of 'size'
> bytes and then memcpy()s 'old_size' bytes into it. If the request is to
> shrink the object (size < old_size), this results in an out-of-bounds
> write on the new buffer.
>
> Fix this by bounding the copy length by the new allocation size.
>
> Fixes: 4c5d3365882d ("mm/vmalloc: allow to set node and align in vrealloc")
> Cc: <sta...@vger.kernel.org>
> Reported-by: Harry Yoo (Oracle) <ha...@kernel.org>
> Signed-off-by: Marco Elver <el...@google.com>

Acked-by: Vlastimil Babka (SUSE) <vba...@kernel.org>

[Harry Yoo (Oracle)]

On Mon, Apr 20, 2026 at 01:47:26PM +0200, Marco Elver wrote:

> Commit 4c5d3365882d ("mm/vmalloc: allow to set node and align in
> vrealloc") added the ability to force a new allocation if the current
> pointer is on the wrong NUMA node, or if an alignment constraint is not
> met, even if the user is shrinking the allocation.
>
> On this path (need_realloc), the code allocates a new object of 'size'
> bytes and then memcpy()s 'old_size' bytes into it. If the request is to
> shrink the object (size < old_size), this results in an out-of-bounds
> write on the new buffer.
>
> Fix this by bounding the copy length by the new allocation size.
>
> Fixes: 4c5d3365882d ("mm/vmalloc: allow to set node and align in vrealloc")
> Cc: <sta...@vger.kernel.org>
> Reported-by: Harry Yoo (Oracle) <ha...@kernel.org>
> Signed-off-by: Marco Elver <el...@google.com>
> ---

Looks good to me,
Reviewed-by: Harry Yoo (Oracle) <ha...@kernel.org>

Thanks a lot for fixing it!

> mm/vmalloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 61caa55a4402..8b1124158f54 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -4361,7 +4361,7 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align
> return NULL;
>
> if (p) {
> - memcpy(n, p, old_size);
> + memcpy(n, p, min(size, old_size));
> vfree(p);
> }
>
> --
> 2.54.0.rc1.513.gad8abe7a5a-goog

--
Cheers,
Harry / Hyeonggon

[Andrew Morton]

On Mon, 20 Apr 2026 13:47:26 +0200 Marco Elver <el...@google.com> wrote:

> Commit 4c5d3365882d ("mm/vmalloc: allow to set node and align in
> vrealloc") added the ability to force a new allocation if the current
> pointer is on the wrong NUMA node, or if an alignment constraint is not
> met, even if the user is shrinking the allocation.
>
> On this path (need_realloc), the code allocates a new object of 'size'
> bytes and then memcpy()s 'old_size' bytes into it. If the request is to
> shrink the object (size < old_size), this results in an out-of-bounds
> write on the new buffer.
>
> Fix this by bounding the copy length by the new allocation size.

AI review is asking questions about the nearby code:
https://sashiko.dev/#/patchset/20260420114805....@google.com

[Marco Elver]

There's kernel-doc wording for this function:

* If __GFP_ZERO logic is requested, callers must ensure that, starting with the
* initial memory allocation, every subsequent call to this API for the same
* memory allocation is flagged with __GFP_ZERO. Otherwise, it is possible that
* __GFP_ZERO is not fully honored by this API.

So while Sashiko is technically right, the API contract says this is
by design. Sashiko should ingest available kernel-doc API contracts if
available.