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

[Marco Elver]

On Fri, 24 Apr 2026 at 15:56, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, 20 Apr 2026 13:47:26 +0200 Marco Elver <elver@xxxxxxxxxx> 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.3572606-2-elver@xxxxxxxxxx

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.