All of lore.kernel.org
 help / color / mirror / Atom feed
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,



  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.