vmalloc: fix buffer overflow in vrealloc_node_align()

PATCH Applied Marco Elver 5 participants 6 messages Apr 20 – Apr 27

Subsystems (3)

Stable branch Memory management vmalloc

lore

Share & tools

lore

Marco Elver

author

2026-04-20 11:49 UTC #0 lore raw

PATCH 1/1 vmalloc: fix buffer overflow in vrealloc_node_align()

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 <[email protected]>

Reported-by Harry Yoo (Oracle) <[email protected]>

Signed-off-by Marco Elver <[email protected]>

---
 mm/vmalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

mm/vmalloc.c +1 -1

index 61caa55a4402..8b1124158f54 100644
@@ -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);
 	}

Signature · 1 line

2.54.0.rc1.513.gad8abe7a5a-goog

Uladzislau Rezki

maintainer Reviewed-by on v1 1/1

2026-04-20 12:17 UTC #1 lore raw

Quoted 36 lines · 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 <[email protected]>
Reported-by Harry Yoo (Oracle) <[email protected]>
Signed-off-by Marco Elver <[email protected]>
---
 mm/vmalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
mm/vmalloc.c +1 -1
index 61caa55a4402..8b1124158f54 100644
@@ -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);
 	}
 
Signature · 1 line
2.54.0.rc1.513.gad8abe7a5a-goog

Agree with a problem described in commit message:

Reviewed-by Uladzislau Rezki (Sony) <[email protected]>

Thank you for fixing it!

--
Uladzislau Rezki

Vlastimil Babka (SUSE)

Acked-by on v1 1/1

2026-04-20 12:21 UTC #2 lore raw

In reply to Marco Elver

Quoted 10 lines · 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.

Quoted 6 lines

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 <[email protected]>
Reported-by Harry Yoo (Oracle) <[email protected]>
Signed-off-by Marco Elver <[email protected]>

Acked-by Vlastimil Babka (SUSE) <[email protected]>

Quoted 17 lines

---
 mm/vmalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

mm/vmalloc.c +1 -1

index 61caa55a4402..8b1124158f54 100644
@@ -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);
 	}

Harry Yoo (Oracle)

Reviewed-by on v1 1/1

2026-04-20 13:04 UTC #3 lore raw

In reply to Marco Elver

Quoted 10 lines · 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.

Quoted 7 lines

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 <[email protected]>
Reported-by Harry Yoo (Oracle) <[email protected]>
Signed-off-by Marco Elver <[email protected]>
---

Looks good to me,

Reviewed-by Harry Yoo (Oracle) <[email protected]>

Thanks a lot for fixing it!

Quoted 18 lines

 mm/vmalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

mm/vmalloc.c +1 -1

index 61caa55a4402..8b1124158f54 100644
@@ -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);
 	}

Signature · 1 line

2.54.0.rc1.513.gad8abe7a5a-goog

Signature · 2 lines

Cheers,
Harry / Hyeonggon

Andrew Morton

maintainer

2026-04-24 13:56 UTC #4 lore raw

In reply to Marco Elver

Quoted 11 lines · On Mon, 20 Apr 2026 13:47:26 +0200 Marco Elver <[email protected]> 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/[email protected]

Marco Elver

author

2026-04-27 11:03 UTC #5 lore raw

Quoted 13 lines · Andrew Morton

Quoted 10 lines · On Mon, 20 Apr 2026 13:47:26 +0200 Marco Elver <[email protected]> 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.

Quoted 4 lines

Quoted 1 line
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/[email protected]

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.