From: sashiko-bot@kernel.org
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: "Alexander Gordeev" <agordeev@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>,
linux-s390@vger.kernel.org, "Vasily Gorbik" <gor@linux.ibm.com>
Subject: Re: [PATCH 04/10] mm/bootmem_info: allow calling free_bootmem_page() on pages without a bootmem_type
Date: Wed, 08 Jul 2026 14:53:48 +0000 [thread overview]
Message-ID: <20260708145348.D5D6E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260708-bootmem_info_part2-v1-4-156ce4986598@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Freeing unregistered vmemmap pages at runtime directly via `free_reserved_page()` bypasses atomic refcount checks, causing a Use-After-Free or double-free when racing with PFN scanners.
--
--- Patch [4]: [PATCH 04/10] mm/bootmem_info: allow calling free_bootmem_page() on pages without a bootmem_type ---
commit a34f9e5045801f37b33acf3125423a2dfdea2fc8
Author: David Hildenbrand (Arm) <david@kernel.org>
Subject: mm/bootmem_info: allow calling free_bootmem_page() on pages without a bootmem_type
This commit allows free_bootmem_page() to temporarily support freeing
unregistered vmemmap pages allocated during boot. Instead of triggering a
BUG, pages without a bootmem_type now fall back to being freed via
free_reserved_page().
> diff --git a/include/linux/bootmem_info.h b/include/linux/bootmem_info.h
> index f724340755e55..486acc6127039 100644
> --- a/include/linux/bootmem_info.h
> +++ b/include/linux/bootmem_info.h
> @@ -44,12 +44,12 @@ static inline void free_bootmem_page(struct page *page)
> {
> enum bootmem_type type = bootmem_type(page);
>
> - VM_BUG_ON_PAGE(page_ref_count(page) != 2, page);
> -
> - if (type == SECTION_INFO || type == MIX_SECTION_INFO)
> + if (type == SECTION_INFO || type == MIX_SECTION_INFO) {
> + VM_WARN_ON_PAGE(page_ref_count(page) != 2, page);
> put_page_bootmem(page);
> - else
> - VM_BUG_ON_PAGE(1, page);
> + } else {
> + free_reserved_page(page);
[Severity: High]
Can this race with PFN scanners and cause a use-after-free or double-free?
Since this is used for freeing unregistered vmemmap pages at runtime (via
HugeTLB Vmemmap Optimization), a physical memory scanner like DAMON might
concurrently iterate over this PFN and take a reference using folio_try_get().
If that happens, calling free_reserved_page() directly here bypasses atomic
refcount checks. Looking at free_reserved_pages() in mm/page_alloc.c, it
unconditionally clobbers any concurrent reference:
mm/page_alloc.c:free_reserved_pages() {
...
for (i = 0; i < nr_pages; i++) {
clear_page_tag_ref(page + i);
ClearPageReserved(page + i);
set_page_count(page + i, 0);
}
...
}
Even scanners that check PageReserved can hit a race window here, as
PageReserved is cleared right before the refcount is forced to 0.
> + }
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260708-bootmem_info_part2-v1-0-156ce4986598@kernel.org?part=4
next prev parent reply other threads:[~2026-07-08 14:53 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 14:10 [PATCH 00/10] mm: remove CONFIG_HAVE_BOOTMEM_INFO_NODE (Part 2) David Hildenbrand (Arm)
2026-07-08 14:10 ` [PATCH 01/10] x86/mm: drop order parameter from free_pagetable() David Hildenbrand (Arm)
2026-07-08 14:22 ` sashiko-bot
2026-07-08 15:15 ` David Hildenbrand (Arm)
2026-07-09 2:32 ` Muchun Song
2026-07-08 14:10 ` [PATCH 02/10] mm: provide free_reserved_pages(), removing x86 variant David Hildenbrand (Arm)
2026-07-08 15:13 ` David Hildenbrand (Arm)
2026-07-09 6:19 ` Muchun Song
2026-07-08 14:10 ` [PATCH 03/10] s390/mm: use free_reserved_pages() in vmem_free_pages() David Hildenbrand (Arm)
2026-07-09 6:12 ` Heiko Carstens
2026-07-09 6:21 ` Muchun Song
2026-07-08 14:10 ` [PATCH 04/10] mm/bootmem_info: allow calling free_bootmem_page() on pages without a bootmem_type David Hildenbrand (Arm)
2026-07-08 14:53 ` sashiko-bot [this message]
2026-07-09 6:23 ` Muchun Song
2026-07-08 14:11 ` [PATCH 05/10] x86/mm: stop marking vmemmap as SECTION_INFO David Hildenbrand (Arm)
2026-07-08 15:10 ` sashiko-bot
2026-07-08 15:20 ` David Hildenbrand (Arm)
2026-07-08 14:11 ` [PATCH 06/10] x86/mm: stop marking page tables as MIX_SECTION_INFO David Hildenbrand (Arm)
2026-07-08 15:24 ` sashiko-bot
2026-07-08 15:27 ` David Hildenbrand (Arm)
2026-07-08 14:11 ` [PATCH 07/10] x86/mm: remove CONFIG_HAVE_BOOTMEM_INFO_NODE David Hildenbrand (Arm)
2026-07-08 15:38 ` sashiko-bot
2026-07-08 14:11 ` [PATCH 08/10] mm/hugetlb_vmemmap: remove bootmem_info leftovers David Hildenbrand (Arm)
2026-07-09 6:26 ` Muchun Song
2026-07-08 14:11 ` [PATCH 09/10] mm/sparse: remove bootmem_info.h include David Hildenbrand (Arm)
2026-07-09 6:26 ` Muchun Song
2026-07-08 14:11 ` [PATCH 10/10] mm/bootmem_info: remove CONFIG_HAVE_BOOTMEM_INFO_NODE David Hildenbrand (Arm)
2026-07-09 6:27 ` Muchun Song
2026-07-08 21:24 ` [PATCH 00/10] mm: remove CONFIG_HAVE_BOOTMEM_INFO_NODE (Part 2) Andrew Morton
2026-07-09 9:36 ` Mike Rapoport
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=20260708145348.D5D6E1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=david@kernel.org \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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