mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Shubhang Kaushik (Ampere)" <sh@gentwo.org>
To: Andrew Morton <akpm@linux-foundation.org>,
	 Uladzislau Rezki <urezki@gmail.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	 Shubhang Kaushik <shubhang@os.amperecomputing.com>,
	 "Christoph Lameter (Ampere)" <cl@gentwo.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	 stable@vger.kernel.org,
	"Shubhang Kaushik (Ampere)" <sh@gentwo.org>
Subject: [PATCH v2] mm/vmalloc: reject overflowing vm_map_ram page counts
Date: Thu, 22 Oct 2026 23:43:47 -0700	[thread overview]
Message-ID: <20261022-vmalloc-reject-overflow-v2-1-0db7a20c53f0@gentwo.org> (raw)

vm_map_ram() accepts a page count and must either map that many pages or
fail. It currently converts the count to a byte size with:

        (unsigned long)count << PAGE_SHIFT

On 32-bit kernels, this conversion overflows when count is greater than
ULONG_MAX >> PAGE_SHIFT. vm_map_ram() then allocates and maps only the
wrapped byte size, but returns a non-NULL address to its caller.

For example, with 4 KiB pages, a count of 1048577 wraps to PAGE_SIZE.
vm_map_ram() therefore returns a mapping containing one page instead of
the requested 1048577 pages.

If a caller uses the successful result as a mapping of all requested
pages, it can access beyond the allocated mapping. Such an access can
fault. If the accessed virtual address is occupied by another vmalloc
mapping, it can instead access and corrupt unrelated kernel memory. In a
userspace-reachable call path, this can result in a failed operation, a
kernel oops or panic, or the effects of corrupted kernel data.

Return NULL before allocating or mapping anything when count * PAGE_SIZE
cannot be represented in an unsigned long.

Fixes: db64fe02258f ("mm: rewrite vmap layer")
Cc: stable@vger.kernel.org
Signed-off-by: Shubhang Kaushik (Ampere) <sh@gentwo.org>
---
Changes in v2:
  - Use check_mul_overflow() to validate the page-count-to-byte conversion.
  - Describe the short-mapping failure mode and its worst-case effects.

Link to v1: https://lore.kernel.org/r/20261022-vmalloc-reject-overflow-v1-1-5fde0042ffb9@gentwo.org
---
 mm/vmalloc.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index bea9f76ed7e74247d4ce919250c2f02dd5c36483..8a056e424a4f2c037c10f736002839014f1f57dc 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -3083,10 +3083,13 @@ EXPORT_SYMBOL(vm_unmap_ram);
  */
 void *vm_map_ram(struct page **pages, unsigned int count, int node)
 {
-	unsigned long size = (unsigned long)count << PAGE_SHIFT;
+	unsigned long size;
 	unsigned long addr;
 	void *mem;
 
+	if (check_mul_overflow((unsigned long)count, PAGE_SIZE, &size))
+		return NULL;
+
 	if (likely(count <= VMAP_MAX_ALLOC)) {
 		mem = vb_alloc(size, GFP_KERNEL);
 		if (IS_ERR(mem))

---
base-commit: 734bef548a96e8774d6eef5dfa2026c6edc4e80b
change-id: 20261022-vmalloc-reject-overflow-e532c556f3fa

Best regards,
-- 
Shubhang Kaushik (Ampere) <sh@gentwo.org>


             reply	other threads:[~2026-10-23  6:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-23  6:43 Shubhang Kaushik (Ampere) [this message]
2026-10-30  3:55 ` Andrew Morton
2026-10-30  6:23 ` Dev Jain

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=20261022-vmalloc-reject-overflow-v2-1-0db7a20c53f0@gentwo.org \
    --to=sh@gentwo.org \
    --cc=akpm@linux-foundation.org \
    --cc=cl@gentwo.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@gmail.com \
    --cc=shubhang@os.amperecomputing.com \
    --cc=stable@vger.kernel.org \
    --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

all inboxes | Powered by JetHome®