From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
To: Ke Zhao <ke.zhao.kernel@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
John Hubbard <jhubbard@nvidia.com>,
Brendan Jackman <jackmanb@google.com>,
Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>,
Alexander Potapenko <glider@google.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
syzbot+2aee6839a252e612ce34@syzkaller.appspotmail.com,
Marco Elver <elver@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
kasan-dev <kasan-dev@googlegroups.com>,
Muhammad Usama Anjum <usama.anjum@arm.com>
Subject: Re: [PATCH] mm, KMSAN: Add missing shadow memory initialization in special allocation paths
Date: Mon, 30 Mar 2026 18:36:27 +0200 [thread overview]
Message-ID: <85f960e5-4988-4fef-9ad5-d5dba580b88d@kernel.org> (raw)
In-Reply-To: <20260330-fix-kmsan-v1-1-e9c672a4b9eb@gmail.com>
+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 <ke.zhao.kernel@gmail.com>
> ---
> 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,
next prev parent reply other threads:[~2026-03-30 16:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-30 8:36 [PATCH] mm, KMSAN: Add missing shadow memory initialization in special allocation paths Ke Zhao
2026-03-30 16:36 ` Vlastimil Babka (SUSE) [this message]
2026-03-30 20:39 ` Usama Anjum
2026-03-31 2:00 ` Ke Zhao
2026-03-31 7:53 ` Muhammad Usama Anjum
2026-03-31 2:04 ` Ke Zhao
2026-03-31 13:38 ` kernel test robot
2026-03-31 14:22 ` kernel test robot
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=85f960e5-4988-4fef-9ad5-d5dba580b88d@kernel.org \
--to=vbabka@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=jhubbard@nvidia.com \
--cc=kasan-dev@googlegroups.com \
--cc=ke.zhao.kernel@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=surenb@google.com \
--cc=syzbot+2aee6839a252e612ce34@syzkaller.appspotmail.com \
--cc=usama.anjum@arm.com \
--cc=ziy@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.