From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 303B939EF1B; Mon, 20 Apr 2026 12:21:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776687710; cv=none; b=lhvj47xeUuOmQ/m5fMPDJz0F1Xtk0urkuxJARdUvK4xBI47FBbEAIEXvQxKetVFvkPkjNJtlRDkz4B8/ecN6bJxOtG1uOl3xrdi0jQ/vtvo6yj65wgYanafQHwXKtJISkD5C3FzJmawaMoG9j268ngLEuP8PE8zyPzydBq+v2qI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776687710; c=relaxed/simple; bh=L9LDa8lva8DgET9ePF+xNKbKYxtkERL5knvaO3eD5ow=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ZPYrwMFcXTfDoz9bnsBvetKf2RvvkQ+T2Yr7FF0hHpu70nnVpSpkUrlbtvl4osLAlBvqJTU9+I76ZgxRoUn+pfFBRVFQcndXEKLd8fuy91CgaDN6My4J32HM1Ngds9UN5ltBHSOPYZ7FxqCpITW9r184Ma2hfnerKu2ilVGqxcA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Jh7qhv4G; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Jh7qhv4G" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F210C19425; Mon, 20 Apr 2026 12:21:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776687709; bh=L9LDa8lva8DgET9ePF+xNKbKYxtkERL5knvaO3eD5ow=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Jh7qhv4G9ma5b299TRCbRaf/U2VwkpsUFEASRJy8uTasa1Ucnz/iiEOWzpNCxm1S2 cngaXjod2Dl5o3xyzEp1AoTOzlfzbZ24otCFDkPHm4pS/YkwrRdp2nemgNYk89dEn2 o0mtRwcpHxBvtdlGPscE9dLHEWwSUgvQL5R+yNdBVcKTcYbt7H+BRbvJd7MCKPZgcL 6AiyfYluWuGLhWzJAg4WBmRaUjzYLy4VTaguXgVJxiYkGi6aRc5TNohGq/WnR8AFjX uq05qdMTAOnm2HAOV7IFPqW+iCijNiC+EBG4ehhlPBsp8rX25qvnOqF9krzJZtFd3N Wk/JHNo9NE2Xw== Message-ID: <759ccf04-345b-4264-a222-3049a20b0263@kernel.org> Date: Mon, 20 Apr 2026 14:21:46 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] vmalloc: fix buffer overflow in vrealloc_node_align() Content-Language: en-US To: Marco Elver , Andrew Morton Cc: Uladzislau Rezki , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Vitaly Wool , stable@vger.kernel.org, "Harry Yoo (Oracle)" References: <20260420114805.3572606-2-elver@google.com> From: "Vlastimil Babka (SUSE)" In-Reply-To: <20260420114805.3572606-2-elver@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: > Reported-by: Harry Yoo (Oracle) > Signed-off-by: Marco Elver Acked-by: Vlastimil Babka (SUSE) > --- > 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); > } >