From nobody Fri Dec 19 22:01:07 2025 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 C6C521E5B68; Thu, 15 May 2025 21:42:20 +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=1747345340; cv=none; b=ngITEB+XLvUsFUVmxmoKnANn5AiTIOCxP8LkgxypWYo8dyX7IMqmE4Jch5qYVwccNXJ83VoXHhhRvj5nZ3wOSvsOrVPp1DpFakcESd7L1kUE7uRJHFwtl/3VDJghHu28k6nkBZhOwt1sfHY2yhwnvL3XlHc9NtiLdZYE8Icmx+s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747345340; c=relaxed/simple; bh=z9irnXGnBvQrp/d6U5i09UQ0eP4PPoB4jFvCw3GG5Eo=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=G5IgTQiLjaQkikyREpJ/i/T4wB/Ug7js1fRf1YOxuKYllvE8loY0to1bMfzV7Js5iTbfXgd0Uz2Ki6kkZpgL91guJ0bcpQHRNpygdMZH8dfsUBDKBcVAnhwFQbW7/RPYTFtx1lNg6rDLB1ye9Ryb6VLrnVyz6bxU49U3hTrk+j4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UQh6mxHc; 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="UQh6mxHc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F700C4CEF0; Thu, 15 May 2025 21:42:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747345340; bh=z9irnXGnBvQrp/d6U5i09UQ0eP4PPoB4jFvCw3GG5Eo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UQh6mxHcqeXKhPT1dyh1SA70xwHpyVoZt0LW0sfH4nslVfzHj/5A0ecGaTQhmgEla 8xvFiuw+WqpvQIXI9o28bXFhgG/pkytvThEZdHBX6/bnkodzWVfW4Ym9V7Wco2UNAQ 9XKQ6aq7c16cv1dYri1r/LD7Rc5//T7ewhaT6hofazb2L18p1NO0JIdRU8xEQQ7qLg VghxvS44eolPCz95bUMzFRStPDNGu6SfqAgXxrlIQk/sV+3zH52l3hxgVH1ukMh396 rhw1uKT1VVCNewzyT9tSYSr9nlgvimQCmZKqj/MqmnYVroWg9xp2zmdH8XSnmYwOwf EwxX30bzsVCQQ== From: Kees Cook To: Andrew Morton Cc: Kees Cook , Shung-Hsi Yu , Eduard Zingerman , Pawan Gupta , Uladzislau Rezki , linux-mm@kvack.org, Erhard Furtner , Danilo Krummrich , linux-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-hardening@vger.kernel.org Subject: [PATCH 1/2] mm: vmalloc: Actually use the in-place vrealloc region Date: Thu, 15 May 2025 14:42:15 -0700 Message-Id: <20250515214217.619685-1-kees@kernel.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20250515214020.work.519-kees@kernel.org> References: <20250515214020.work.519-kees@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1153; i=kees@kernel.org; h=from:subject; bh=z9irnXGnBvQrp/d6U5i09UQ0eP4PPoB4jFvCw3GG5Eo=; b=owGbwMvMwCVmps19z/KJym7G02pJDBlq8dun79rx688HA96MI6Yvt5nG6022C/q6d2GEvJvK2 yPs8woDOkpZGMS4GGTFFFmC7NzjXDzetoe7z1WEmcPKBDKEgYtTACbSrsvI8Dq8eW+R9P5/5V8k 5h7rmm2nfaLoUmRj2+Ldpn88GBI/KDD8D+ozsv6UVmDQuj7qyrqO7+93/bh8/7FV53W974kRTqw MfAA= X-Developer-Key: i=kees@kernel.org; a=openpgp; fpr=A5C3F68F229DD60F723E6E138972F4DFDC6DC026 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The refactoring to not build a new vmalloc region only actually worked when shrinking. Actually return the resized area when it grows. Ugh. Reported-by: Shung-Hsi Yu Closes: https://lore.kernel.org/all/20250515-bpf-verifier-slowdown-vwo2meju= 4cgp2su5ckj@6gi6ssxbnfqg Tested-by: Eduard Zingerman Tested-by: Pawan Gupta Fixes: a0309faf1cb0 ("mm: vmalloc: support more granular vrealloc() sizing") Signed-off-by: Kees Cook Reviewed-by: "Uladzislau Rezki (Sony)" Reviewed-by: Danilo Krummrich Tested-by: Shung-Hsi Yu --- Cc: Andrew Morton Cc: Uladzislau Rezki Cc: --- mm/vmalloc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 2d7511654831..74bd00fd734d 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -4111,6 +4111,7 @@ void *vrealloc_noprof(const void *p, size_t size, gfp= _t flags) if (want_init_on_alloc(flags)) memset((void *)p + old_size, 0, size - old_size); vm->requested_size =3D size; + return (void *)p; } =20 /* TODO: Grow the vm_area, i.e. allocate and map additional pages. */ --=20 2.34.1 From nobody Fri Dec 19 22:01:07 2025 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 C6CC2289823; Thu, 15 May 2025 21:42:20 +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=1747345340; cv=none; b=AW4YkLKKo0ElbRbPV2de0meZDNPdd6Ob6klDhC7urel2zw/C/nBgk6P+NlhqyATXt7FGdbY47bFtwHnxYSpxTN3RNt4sIiINzNAMT2K966AzbxrsRYCmIchtM8KkB7diSXbTG/HxSOMMHJtSj+IINxe29HDaG+s25UGujGLDQyc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747345340; c=relaxed/simple; bh=y5iTm0qa00qIrnZejVeX3Ab8YTjp2BAj50nhyhXZ9E4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Nrhg/jocBVG1Uo5fjL/tiEUoejmtWSOObc71Z2xmhspwK7aEU1YI/F5ESjQwJM728mPVxGl0qi5yzQT7ofFqNGE2XHTlIjreuOwAs8dwTYDEDr8DWTwe+cUjysp47AFdKaOQHlAfS8c2h6OkirAIXacYi8n77QLFHUxRVk0Gn7k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GlYj4bdU; 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="GlYj4bdU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3D882C4CEE7; Thu, 15 May 2025 21:42:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747345340; bh=y5iTm0qa00qIrnZejVeX3Ab8YTjp2BAj50nhyhXZ9E4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GlYj4bdUgtKWdopH5Pm0KQqKQLoi5ebsh9SGDJPFtGS/tq0yzDFb/xQRJ6XDphmK2 AbTtexUtTLD0iK1DTbQ9RISyVa2NU9xYPZI8c28vBG/aAYjxOWJML3zIHT8TxriRGf 1zqyN/7ef1sPBXRes3tezLn0+rvGzaWWm2zaIeavxcitwcufirPgsCLMKPAJQVh85U tXMspr70v5LARinfIxDEK4GPz9uLenK3ElOcAaYSGaibfeTBJ2dlLRKKuCBGp1hZVC eAbYZUt/JqjLCxexwFPYdZztazWyfYVUz1qDbv8PZKFbirA0NYfx/Y09rpz+cTo6q6 t17EaUkC9zyVQ== From: Kees Cook To: Andrew Morton Cc: Kees Cook , Pawan Gupta , Uladzislau Rezki , linux-mm@kvack.org, Shung-Hsi Yu , Eduard Zingerman , Erhard Furtner , Danilo Krummrich , linux-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-hardening@vger.kernel.org Subject: [PATCH 2/2] mm: vmalloc: Only zero-init on vrealloc shrink Date: Thu, 15 May 2025 14:42:16 -0700 Message-Id: <20250515214217.619685-2-kees@kernel.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20250515214020.work.519-kees@kernel.org> References: <20250515214020.work.519-kees@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1777; i=kees@kernel.org; h=from:subject; bh=y5iTm0qa00qIrnZejVeX3Ab8YTjp2BAj50nhyhXZ9E4=; b=owGbwMvMwCVmps19z/KJym7G02pJDBlq8TuaP1/5N3W32tZO4QqDVerPORc8t9S/psUZEv6ox JvlxmXmjlIWBjEuBlkxRZYgO/c4F4+37eHucxVh5rAygQxh4OIUgIl8Pc3whzvzwoNPi1+wqptH 77Zgl6l9MXFPvd4kjhTdy219X3+zGjEy7GmpLt4vcJMrV+tMwK3ur+vnbeL8bHNpo8vuL1qfy78 bswEA X-Developer-Key: i=kees@kernel.org; a=openpgp; fpr=A5C3F68F229DD60F723E6E138972F4DFDC6DC026 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The common case is to grow reallocations, and since init_on_alloc will have already zeroed the whole allocation, we only need to zero when shrinking the allocation. Fixes: a0309faf1cb0 ("mm: vmalloc: support more granular vrealloc() sizing") Tested-by: Pawan Gupta Signed-off-by: Kees Cook Reviewed-by: "Uladzislau Rezki (Sony)" Reviewed-by: Danilo Krummrich Tested-by: Shung-Hsi Yu --- Cc: Andrew Morton Cc: Uladzislau Rezki Cc: --- mm/vmalloc.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 74bd00fd734d..00cf1b575c89 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -4093,8 +4093,8 @@ void *vrealloc_noprof(const void *p, size_t size, gfp= _t flags) * would be a good heuristic for when to shrink the vm_area? */ if (size <=3D old_size) { - /* Zero out "freed" memory. */ - if (want_init_on_free()) + /* Zero out "freed" memory, potentially for future realloc. */ + if (want_init_on_free() || want_init_on_alloc(flags)) memset((void *)p + size, 0, old_size - size); vm->requested_size =3D size; kasan_poison_vmalloc(p + size, old_size - size); @@ -4107,9 +4107,11 @@ void *vrealloc_noprof(const void *p, size_t size, gf= p_t flags) if (size <=3D alloced_size) { kasan_unpoison_vmalloc(p + old_size, size - old_size, KASAN_VMALLOC_PROT_NORMAL); - /* Zero out "alloced" memory. */ - if (want_init_on_alloc(flags)) - memset((void *)p + old_size, 0, size - old_size); + /* + * No need to zero memory here, as unused memory will have + * already been zeroed at initial allocation time or during + * realloc shrink time. + */ vm->requested_size =3D size; return (void *)p; } --=20 2.34.1