From mboxrd@z Thu Jan 1 00:00:00 1970 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 7590C3815EC for ; Mon, 30 Mar 2026 16:36:32 +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=1774888592; cv=none; b=VyZCfOv4umTb0J5CK/19WJLkcnNoeGal7MS/5AXyFONZljGzL22t+Zn+eCFGjI8eZw6W3oq1AqIWRvMJtgRBEJvrEDQXGT8gnRDXxLmWNWyZDquTq1lFgIwkoILw4F2j3IGvq/DTovstM329joOiYaKVKWEgsoaCQe1h0uQuz24= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774888592; c=relaxed/simple; bh=anKl0l7R5c+w69kw36S4RIdGWUZ6FVWmpssD4MxoZN4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=NHYrd0oCcp2jllkojqPZBBxfOBIcuo6//HO0a2PZIIfL5GMSlfU12yp6nnooNNGjdeVQXAhkHC+O5EEcjM2s4SzFj8UqGSaw6IFQLJqKJjAqwKN0GKB4xk+QW+0HqtLqzJQcjnthfve22KYVu5uiR2PmpggVVhh3bLVE0fAllkk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=l2pglG4S; 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="l2pglG4S" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0EFCDC4CEF7; Mon, 30 Mar 2026 16:36:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774888592; bh=anKl0l7R5c+w69kw36S4RIdGWUZ6FVWmpssD4MxoZN4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=l2pglG4SHR9jCapiqjEkHhpE1dKCDO3YV4lDIYqtL0/kNMkYmLWUF9eGy21+sgmMY 8AJIcgqeWayh13xWk9+pe+llp3FCMDF5VFRkvDtgtrFrSRFhXcM9rqGPWmJ1fQSW2M g4uOIORrHmqmH6VC28UgRJ9n26oSIwGQgBVHzL8qn3a2hBFi81D9+kJf3vnIleySgF O26CFWHzw2vPqymqR0FBk251Jz2iOMkJTcPREz9j55S/LIdB1XFUEWdNjBb+7DkCrI Q+8NZvtpUxzLrjXyj7+MMC/DcPJEdatv5q29U8LfulwQjZcLF+8ziR4uMGceW8AAUF ymbXZ35d8o5kA== Message-ID: <85f960e5-4988-4fef-9ad5-d5dba580b88d@kernel.org> Date: Mon, 30 Mar 2026 18:36:27 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm, KMSAN: Add missing shadow memory initialization in special allocation paths Content-Language: en-US To: Ke Zhao , Andrew Morton , Suren Baghdasaryan , Michal Hocko , John Hubbard , Brendan Jackman , Johannes Weiner , Zi Yan , Alexander Potapenko Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, syzbot+2aee6839a252e612ce34@syzkaller.appspotmail.com, Marco Elver , Dmitry Vyukov , kasan-dev , Muhammad Usama Anjum References: <20260330-fix-kmsan-v1-1-e9c672a4b9eb@gmail.com> From: "Vlastimil Babka (SUSE)" In-Reply-To: <20260330-fix-kmsan-v1-1-e9c672a4b9eb@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit +Cc KMSAN folks, please review On 3/30/26 10:36, Ke Zhao wrote: > Some page allocation paths that call post_alloc_hook() but skip > kmsan_alloc_page(), leaving stale KMSAN shadow on allocated pages. > Fix this by explicitly calling kmsan_alloc_page() after they > successfully get new pages. > > Reported-by: syzbot+2aee6839a252e612ce34@syzkaller.appspotmail.com FYI the report thread: https://lore.kernel.org/all/698f1877.a70a0220.2c38d7.00c2.GAE@google.com/ > Closes: https://syzkaller.appspot.com/bug?extid=2aee6839a252e612ce34 Did syzbot confirm it as fix? Wonder if this submission alone will trigger that check without some syz test command or whatnot. > > Signed-off-by: Ke Zhao > --- > mm/page_alloc.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 2d4b6f1a554e..6435e8708ef4 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -5189,6 +5189,10 @@ unsigned long alloc_pages_bulk_noprof(gfp_t gfp, int preferred_nid, > > prep_new_page(page, 0, gfp, 0); > set_page_refcounted(page); > + > + trace_mm_page_alloc(page, 0, gfp, ac.migratetype); Probably makes sense to add that here, yeah. > + kmsan_alloc_page(page, 0, gfp); > + > page_array[nr_populated++] = page; > } > > @@ -6911,6 +6915,12 @@ static void split_free_frozen_pages(struct list_head *list, gfp_t gfp_mask) > int i; > > post_alloc_hook(page, order, gfp_mask); > + /* > + * Initialize KMSAN state right after post_alloc_hook(). > + * This prepares the pages for subsequent outer callers > + * that might free sub-pages after the split. > + */ > + kmsan_alloc_page(page, order, gfp_mask); > if (!order) > continue; > > @@ -7117,6 +7127,9 @@ int alloc_contig_frozen_range_noprof(unsigned long start, unsigned long end, > > check_new_pages(head, order); > prep_new_page(head, order, gfp_mask, 0); > + > + trace_mm_page_alloc(page, order, gfp_mask, get_pageblock_migratetype(page)); But I'm not sure we want to use this trace event here, minimally it would be inconsistent with the branch above using split_free_frozen_pages()? > + kmsan_alloc_page(page, order, gfp_mask); > } else { > ret = -EINVAL; > WARN(true, "PFN range: requested [%lu, %lu), allocated [%lu, %lu)\n", > > --- > base-commit: bbeb83d3182abe0d245318e274e8531e5dd7a948 > change-id: 20260325-fix-kmsan-e291f752a949 > > Best regards,