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
prev parent 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 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.