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