From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C1C5A3EC83C for ; Thu, 30 Jul 2026 09:06:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785402415; cv=none; b=IGo0jytafmYFbofq2c5f3OD/EN5dvVPfhsyHT3iNfUYCPcoOllQ43HrPlhj4p3h+lU2RwSp3SgTjkgvR7wtC9pdc6mXk3x1YT/2jfA8A19T2xfRQjqDKsSaeF06jMr/seWdymjuAFJWKv+qEGYtyKZDWUtsxqoL49Tsm9YDshqc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785402415; c=relaxed/simple; bh=0H9xIjYjvCXD6ZQw1IdOnwNfkrIdGCrtWSyEVkQY0Ek=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DSIjp5AVkEaowqdwZgGC87q5IoQiLd2JyiOEALGWo/dqLjG8jI+czasgk3V3ujiJYSi7hnh5mmvKJL05BXZXraGlPyrMFuHI50wAfsedvhtBiiyize8joSics05/NYkCAVikJEdD5IPsy0GZrUAD8nFokGplpdUoj5w2J/Wm1Tw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=l/eNF6qc; arc=none smtp.client-ip=209.85.208.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="l/eNF6qc" Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-39c8dbf4f38so15267331fa.3 for ; Thu, 30 Jul 2026 02:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785402412; x=1786007212; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=/6CocFUoEfqFYcrJ0dBCPJIkk+HjBh479KEdCNfDi1g=; b=l/eNF6qcOxEcV861uUkcxzu6fVTMVDX3RqwgNd4ZCl34k7jBmdKcJOUQqMi5JpmHcL /KMSSXA+ojYwPAIiRDQ1Zei8W0pbkj3PDwru55ZvXInFAncy8VZnbJhCCoSf46Edc9MO 71DiQUWaMrkIMvsNW6pN24HTPGuh9bhA/S3y6QyaDZBFCQyDWmqqwbw+8luzb/IZOpFA 2qbnvELqfdH0wnIqLZaVyySjzWwDP5DSPIak+/MotpTWwNkyvRDD3NDWQCQCq3QGVGng G2atC2pjnj9KFyyhONPoNe4eCSgnOWGbk05Q+H9fLedz4obVtXhWHdeRFZPJ220NAujM PlXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785402412; x=1786007212; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=/6CocFUoEfqFYcrJ0dBCPJIkk+HjBh479KEdCNfDi1g=; b=XO6b1Psxzrxfbq1bhkit1lpmguJ+g9j+7BDhpsko8es9THbMeOX9gS6FR5RUOIAUnx PCZgbUd+KqJZXCVzoCCwZ+6+lglhq+VVXYr5qATEdNtJPT4ydHxcmp7lpo4WAm3Zzs5y ZAtatOvasq9uYTrO1DiEcu6zqyGdjefXCmc5VAgd8/mJRb+UzKq4WGkiTe4Ifay8quDy tMBG2dI0g8P/GBkHwVytaqrwOZA4j/chlSe92etENEmFWGoF0B/MkS2ijLFK0442RQ1x Wq2fISu7W2uLLJFJr3uJ7fy9FNNNG9SlxEtau1MsdOYku3OjFzZwcSgMZ8GMuk3FJ9Iy 3pdg== X-Forwarded-Encrypted: i=1; AHgh+Ro1fnB2jVd4k/CHoLb5uvOtjSsMdmpFJY1jhAsXMc6vS+NN1VxlDzljmSig6hvwZJt5aiHbBCaD1breePI=@vger.kernel.org X-Gm-Message-State: AOJu0YyX64HifM9ukn869O9Ry06nf1kFLLwYzO3f1Nbo5wmt1cdh1mus 6fOMbPWOJD+Iv4o5mEvljJoAr/0xrUPG+s9FJynqlbcCmogEntfxDErt X-Gm-Gg: AR+sD11zpUQUJ5dxq6LOxnwhZGjAg/Z0df7CvIWReQef9woPHl15r70n3kh5tf/AeCA wTDbkZUsZwNUi367CYGHh7BighcRLnU2bRZDtGIb/6VhU7NsqOPCaDAyZCCp2Fn+OVjqZ0uLPnt 2y0dz4/beMBHY1kZD3AUCUrLduqOH9BA0QXaD9+T3qWGirfA8xC4z9sdRziK3DjDv98utNhTAHr zPzD7kKEGPTEv4dnGKk1Vfbz7PkW3FBTAVxRAQTC7jmyF95JnctZJd6vbAca3NchgBqICq1G6sw kYDi+TcSbCcGBWSexO5qspWizbvQdhce67DFo5kqAJKb808PM4JhOk4R7ILSlU3C5dW3HUxgpO6 pO4vxQlrOgujZn5WuYd93WPJcVAjhhyo4hOz3gF6o4NNjCO9+bdUpnBfOKYsmQOfhrfwomk79xx D/s8M0/gIYNF2js+HNkIDpn6Uwsmtxwc6LV1G0pme89rGQpbxEROyxiGMOnSp6cfNY4WkuPk0zr S1hR4BDAun/6vngvz62EGMeF+YQVFY5/on9Lh0x4zw9ZXSysbbnVdgpSQ== X-Received: by 2002:a05:651c:35c6:b0:39f:27a4:8043 with SMTP id 38308e7fff4ca-39f6d0bf78emr3208951fa.37.1785402411664; Thu, 30 Jul 2026 02:06:51 -0700 (PDT) Received: from localhost.localdomain (46-138-176-102.dynamic.spd-mgts.ru. [46.138.176.102]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-39f6ac80d6bsm1928641fa.29.2026.07.30.02.06.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Jul 2026 02:06:51 -0700 (PDT) From: Artem Lytkin To: linux-mm@kvack.org Cc: akpm@linux-foundation.org, urezki@gmail.com, willy@infradead.org, shivamkalra98@zohomail.in, linux-kernel@vger.kernel.org Subject: [PATCH v2 2/3] mm/vmalloc: fix 32-bit truncation in the vrealloc() grow-in-place check Date: Thu, 30 Jul 2026 12:06:27 +0300 Message-ID: <20260730090628.65814-3-iprintercanon@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260729175708.7074-1-iprintercanon@gmail.com> References: <20260729175708.7074-1-iprintercanon@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 --- mm/vmalloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 34e10b825889a..bf9e32cf93fc9 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -4588,7 +4588,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