From nobody Mon Apr 6 09:33:54 2026 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 A3F30258EC2 for ; Sat, 21 Mar 2026 18:05:53 +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=1774116353; cv=none; b=Jqu2lrh6we46iJkvRE5mSVfFDXABDQXgB9UeYsslxSNjFIdZjr5HuOZmtnnw1+l4K75UPIoGA1sOf3WvxEsOxBAW+trtr0HHwagPT4vJn+4H8yobhiqa6zMnefz1hH7RN7aUiiLbiLWElY0bVuxFDON3dxFboFLURJeaPT/kN/w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774116353; c=relaxed/simple; bh=mH1bbzg1toElM+aYhUOHKFjoyynXL2nUy0Bs26YrHAk=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=iE8+GSRuJu6vbJ4WDtVzO2tFSq2Ge2axACKAKRRMbg1tj7SWroehPorTShcuAmzc1U2IDjBxg5UErM42iFLsUA64xaREK4NjIHrQswCwapnGs51ooF2UTpxDBDho1nuo3EMOx3PUhgsT5Wg6tUasMSnvYozgMicWPZxuhsguCsk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VHvRtlHi; 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="VHvRtlHi" Received: by smtp.kernel.org (Postfix) with ESMTPS id 77D59C2BCB3; Sat, 21 Mar 2026 18:05:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774116353; bh=mH1bbzg1toElM+aYhUOHKFjoyynXL2nUy0Bs26YrHAk=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=VHvRtlHi/oByD79fv48x6iNOcazJsOSFTHHkzO4noHSGPOpUtzvjwx2WkqpKLfrM/ NxGxGM5BMJ1psArZpsfahO1N3UkoAQ4f+Sd1Jq0D76Gl2x9cxiBElYIb1psAvW1uH0 Tr+WrnoUO+pZCxWaK5j2eEJINYlNtKSKJmHaaaQO2uHhN0iHfsBi41vAAtvpCr0I6E XPiN498BXqJBP3Ju8/h/ZHJjQ6QGmIT2fmnv53CW8AfR/P6C+6+G/+xphlL/pZyc5X NoALVJ8owxqvX/pplQYFkyPbaQ0acZsRBroV4HJ3NuEBYYz6lg32aM0Emba3UQkBg7 n/7Z9Y7q10cdQ== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6B3D3109446F; Sat, 21 Mar 2026 18:05:53 +0000 (UTC) From: Shivam Kalra via B4 Relay Date: Sat, 21 Mar 2026 23:35:48 +0530 Subject: [PATCH v6 3/6] mm/vmalloc: zero newly exposed memory on vrealloc() grow Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260321-vmalloc-shrink-v6-3-062ca7b7ceb2@zohomail.in> References: <20260321-vmalloc-shrink-v6-0-062ca7b7ceb2@zohomail.in> In-Reply-To: <20260321-vmalloc-shrink-v6-0-062ca7b7ceb2@zohomail.in> To: Andrew Morton , Uladzislau Rezki Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Alice Ryhl , Danilo Krummrich , Shivam Kalra X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1774116351; l=1805; i=shivamkalra98@zohomail.in; s=20260212; h=from:subject:message-id; bh=uKz24R3I3ek2aPMpo8mT2jA7mZwUk/0kKs44mZjEWwY=; b=SbEulE6vIyO33qNSsTDaNxkXiPh02FBirztOinNJUvoERwLlk3BZOWFs/TSe/RbqSHokKF19L hkAhCqBBgK7DPZC6cRSoEnAdkjU3g8wmoC8brnpz5Q6Dahv1SOjUhu3 X-Developer-Key: i=shivamkalra98@zohomail.in; a=ed25519; pk=9Q+S1LD/xjbjL7bEaLIlwRADBwU/6LJq7lYm8LFrkQE= X-Endpoint-Received: by B4 Relay for shivamkalra98@zohomail.in/20260212 with auth_id=633 X-Original-From: Shivam Kalra Reply-To: shivamkalra98@zohomail.in From: Shivam Kalra When growing an existing vmalloc allocation in-place, zero the newly exposed memory region [old_size, size) if the caller requested it via __GFP_ZERO (checked via want_init_on_alloc(flags)). Previously, the code assumed that the unused capacity in the vm_struct was already zeroed either at initial allocation time or during a prior shrink. However, if an intermediate shrink operation occurred without __GFP_ZERO and without init_on_free enabled, the "freed" portion of the allocation would retain its old data. If a subsequent grow-in-place operation then explicitly requests __GFP_ZERO, failing to zero the memory here would violate the allocation flags and leak the previously discarded, potentially sensitive data. Signed-off-by: Shivam Kalra --- mm/vmalloc.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 7bc7a6892c1a..64f5d1088281 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -4362,13 +4362,16 @@ void *vrealloc_node_align_noprof(const void *p, siz= e_t size, unsigned long align * We already have the bytes available in the allocation; use them. */ if (size <=3D (size_t)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 - * realloc shrink time. - */ vm->requested_size =3D size; kasan_vrealloc(p, old_size, size); + + /* + * Zero the newly exposed bytes if requested. + * The region [old_size, size) may contain stale data from + * a previous shrink that did not use __GFP_ZERO. + */ + if (want_init_on_alloc(flags)) + memset((void *)p + old_size, 0, size - old_size); return (void *)p; } =20 --=20 2.43.0