Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mark Bundschuh" <mkbund@amazon.com>
Cc: sashal@kernel.org, linux-mm@kvack.org, david@kernel.org,
	"Ge Yang" <yangge1116@126.com>,
	"Muchun Song" <muchun.song@linux.dev>,
	"Oscar Salvador" <osalvador@suse.de>,
	"Baolin Wang" <baolin.wang@linux.alibaba.com>,
	"Barry Song" <21cnbao@gmail.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: [PATCH v2 5.15 2/2] mm/hugetlb: fix kernel NULL pointer dereference when replacing free hugetlb folios
Date: Sat, 07 Nov 2026 22:05:28 +0000	[thread overview]
Message-ID: <sashiko-outbox-203353@kernel.org> (raw)
In-Reply-To: <20261106220445.2859944-3-mkbund@amazon.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] mm/hugetlb: compound_head() evaluated outside hugetlb_lock in
  replace_free_hugepage_folios()
--

commit de1b340d0acd3398ffa967e9c36bcd2099c3b383
Author: Ge Yang <yangge1116@126.com>

mm/hugetlb: fix kernel NULL pointer dereference when replacing free hugetlb folios

This commit acquires hugetlb_lock around PageHuge() and page_hstate() in
replace_free_hugepage_folios() to prevent racing with concurrent hugepage
freeing.

Link: https://lkml.kernel.org/r/1747884137-26685-1-git-send-email-yangge1116@126.com

> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 4fb98320f9df3..3d7e8826e4525 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2756,12 +2756,20 @@ int replace_free_hugepage_folios(unsigned long start_pfn, unsigned long end_pfn)
>  
>  	while (start_pfn < end_pfn) {
>  		page = compound_head(pfn_to_page(start_pfn));
> +
> +		/*
> +		 * The page might have been dissolved from under our feet, so make sure
> +		 * to carefully check the state under the lock.
> +		 */
> +		spin_lock_irq(&hugetlb_lock);
>  		if (PageHuge(page)) {
>  			h = page_hstate(page);
>  		} else {
> +			spin_unlock_irq(&hugetlb_lock);
>  			start_pfn++;
>  			continue;
>  		}
> +		spin_unlock_irq(&hugetlb_lock);

[Severity: Medium]
Can page_hstate(page) still return NULL if pfn_to_page(start_pfn) becomes a
tail page of a newly prepared hugepage before hugetlb_lock is acquired?

CPU0                                    CPU1
replace_free_hugepage_folios()
  page = compound_head(pfn_to_page(start_pfn))
                                        alloc_gigantic_page() / prep_new_huge_page()
                                          prep_compound_gigantic_page()
                                            /* page becomes a tail page */
                                          spin_lock_irq(&hugetlb_lock)
                                          __prep_new_huge_page()
                                            set_compound_page_dtor(HUGETLB_PAGE_DTOR)
                                          spin_unlock_irq(&hugetlb_lock)
  spin_lock_irq(&hugetlb_lock)
  if (PageHuge(page))
    h = page_hstate(page)  <-- returns NULL
  spin_unlock_irq(&hugetlb_lock)
  alloc_and_dissolve_huge_page(h, page, ...)
    htlb_alloc_mask(h)  <-- NULL pointer dereference

In upstream 113ed54ad276 ("mm/hugetlb: fix kernel NULL pointer dereference
when replacing free hugetlb folios"), pfn_folio(start_pfn) is checked with
folio_test_hugetlb(), which returns false for tail pages.  In 5.15,
PageHuge(page) resolves compound_head(page) internally on its local parameter
and returns true for tail pages, while page_hstate(page) calls
page_size(page) -> compound_order(page), which returns 0 when !PageHead(page)
and causes size_to_hstate(PAGE_SIZE) to return NULL.

Re-evaluating page = compound_head(page) under hugetlb_lock after
PageHuge(page) succeeds, as isolate_or_dissolve_huge_page() and
dissolve_free_huge_page() do, avoids passing a tail page to page_hstate() and
alloc_and_dissolve_huge_page().

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106220445.2859944-1-mkbund@amazon.com?part=2


      reply	other threads:[~2026-11-07 22:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-05  7:02 [PATCH 5.15] mm: replace free hugepage folios after migration Mark Bundschuh
2026-11-06  7:03 ` sashiko-bot
2026-11-06  7:46 ` David Hildenbrand (Arm)
2026-11-06 22:04 ` [PATCH v2 5.15 0/2] " Mark Bundschuh
2026-11-06 22:04   ` [PATCH v2 5.15 1/2] " Mark Bundschuh
2026-11-07 22:05     ` sashiko-bot
2026-11-06 22:04   ` [PATCH v2 5.15 2/2] mm/hugetlb: fix kernel NULL pointer dereference when replacing free hugetlb folios Mark Bundschuh
2026-11-07 22:05     ` sashiko-bot [this message]

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=sashiko-outbox-203353@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=21cnbao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@kernel.org \
    --cc=david@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=mkbund@amazon.com \
    --cc=muchun.song@linux.dev \
    --cc=osalvador@suse.de \
    --cc=sashal@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yangge1116@126.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox