Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Lytkin <iprintercanon@gmail.com>
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, urezki@gmail.com,
	shivamkalra98@zohomail.in, linux-kernel@vger.kernel.org
Subject: [PATCH 2/2] mm/vmalloc: fix 32-bit truncation in the vrealloc() grow-in-place check
Date: Sat, 25 Jul 2026 16:22:01 +0300	[thread overview]
Message-ID: <20260725132201.88279-2-iprintercanon@gmail.com> (raw)

Commit d57ac904ffdc ("mm/vmalloc: use physical page count for vrealloc()
grow-in-place check") introduced

	if (size <= vm->nr_pages << PAGE_SHIFT) {

in place of a comparison against a size_t. As vm->nr_pages is an
unsigned int and a shift is evaluated in the type of its promoted left
operand, the right hand side is computed in 32-bit arithmetic and wraps
for areas of 4 GiB or more. Twelve lines above, in the same function,
four expressions cast for exactly this reason:

	kmemleak_free_part((void *)addr + ((unsigned long)new_nr_pages
					   << PAGE_SHIFT), ...);

The consequence here is benign. Truncation only ever makes the right
hand side smaller than the real capacity, so the test can only fail when
it should have succeeded: vrealloc() then falls through to need_realloc,
allocates a new area, copies min(size, old_size) bytes and frees the old
one. That is correct, only wasteful, and no in-tree caller currently
grows an allocation past 4 GiB, so this is a latent fix rather than a
user-visible one.

Widen the shift to match the surrounding code. Note that comparing page
counts instead, as in PAGE_ALIGN(size) >> PAGE_SHIFT <= vm->nr_pages,
would avoid the cast but introduce a real bug: PAGE_ALIGN() wraps to 0
for sizes within a page of ULONG_MAX and the test would then wrongly
succeed.

Fixes: d57ac904ffdc ("mm/vmalloc: use physical page count for vrealloc() grow-in-place check")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Artem Lytkin <iprintercanon@gmail.com>
---
 mm/vmalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 44647e189f7d6..baf7e396e3fc7 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -4415,7 +4415,7 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align
 	/*
 	 * We already have the bytes available in the allocation; use them.
 	 */
-	if (size <= vm->nr_pages << PAGE_SHIFT) {
+	if (size <= (unsigned long)vm->nr_pages << PAGE_SHIFT) {
 		/*
 		 * No need to zero memory here, as unused memory will have
 		 * already been zeroed at initial allocation time or during
-- 
2.43.0



                 reply	other threads:[~2026-07-25 13:22 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260725132201.88279-2-iprintercanon@gmail.com \
    --to=iprintercanon@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=shivamkalra98@zohomail.in \
    --cc=urezki@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox