linux-kernel - Re: [RFC mm v6] mm: introduce a new page type for page pool in page type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251118011831.GA7184@system.software.com>
Date: Tue, 18 Nov 2025 10:18:31 +0900
From: Byungchul Park <byungchul@...com>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>
Cc: Jesper Dangaard Brouer <hawk@...nel.org>, linux-mm@...ck.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	kernel_team@...ynix.com, harry.yoo@...cle.com, ast@...nel.org,
	daniel@...earbox.net, davem@...emloft.net, kuba@...nel.org,
	john.fastabend@...il.com, sdf@...ichev.me, saeedm@...dia.com,
	leon@...nel.org, tariqt@...dia.com, mbloch@...dia.com,
	andrew+netdev@...n.ch, edumazet@...gle.com, pabeni@...hat.com,
	akpm@...ux-foundation.org, lorenzo.stoakes@...cle.com,
	Liam.Howlett@...cle.com, vbabka@...e.cz, rppt@...nel.org,
	surenb@...gle.com, mhocko@...e.com, horms@...nel.org,
	jackmanb@...gle.com, hannes@...xchg.org, ziy@...dia.com,
	ilias.apalodimas@...aro.org, willy@...radead.org,
	brauner@...nel.org, kas@...nel.org, yuzhao@...gle.com,
	usamaarif642@...il.com, baolin.wang@...ux.alibaba.com,
	almasrymina@...gle.com, toke@...hat.com, asml.silence@...il.com,
	bpf@...r.kernel.org, linux-rdma@...r.kernel.org,
	sfr@...b.auug.org.au, dw@...idwei.uk, ap420073@...il.com,
	dtatulea@...dia.com
Subject: Re: [RFC mm v6] mm: introduce a new page type for page pool in page
 type

On Tue, Nov 18, 2025 at 10:07:35AM +0900, Byungchul Park wrote:
> On Mon, Nov 17, 2025 at 05:47:05PM +0100, David Hildenbrand (Red Hat) wrote:
> > On 17.11.25 17:02, Jesper Dangaard Brouer wrote:
> > > 
> > > On 17/11/2025 06.20, Byungchul Park wrote:
> > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > > index 600d9e981c23..01dd14123065 100644
> > > > --- a/mm/page_alloc.c
> > > > +++ b/mm/page_alloc.c
> > > > @@ -1041,7 +1041,6 @@ static inline bool page_expected_state(struct page *page,
> > > >    #ifdef CONFIG_MEMCG
> > > >                      page->memcg_data |
> > > >    #endif
> > > > -                    page_pool_page_is_pp(page) |
> > > >                      (page->flags.f & check_flags)))
> > > >              return false;
> > > > 
> > > > @@ -1068,8 +1067,6 @@ static const char *page_bad_reason(struct page *page, unsigned long flags)
> > > >      if (unlikely(page->memcg_data))
> > > >              bad_reason = "page still charged to cgroup";
> > > >    #endif
> > > > -    if (unlikely(page_pool_page_is_pp(page)))
> > > > -            bad_reason = "page_pool leak";
> > > >      return bad_reason;
> > > >    }
> > > 
> > > This code have helped us catch leaks in the past.
> > > When this happens the result is that the page is marked as a bad page.
> > > 
> > > > 
> > > > @@ -1378,9 +1375,12 @@ __always_inline bool free_pages_prepare(struct page *page,
> > > >              mod_mthp_stat(order, MTHP_STAT_NR_ANON, -1);
> > > >              folio->mapping = NULL;
> > > >      }
> > > > -    if (unlikely(page_has_type(page)))
> > > > +    if (unlikely(page_has_type(page))) {
> > > > +            /* networking expects to clear its page type before releasing */
> > > > +            WARN_ON_ONCE(PageNetpp(page));
> > > >              /* Reset the page_type (which overlays _mapcount) */
> > > >              page->page_type = UINT_MAX;
> > > > +    }
> > > > 
> > > >      if (is_check_pages_enabled()) {
> > > >              if (free_page_is_bad(page))
> > > 
> > > What happens to the page? ... when it gets marked with:
> > >     page->page_type = UINT_MAX
> > > 
> > > Will it get freed and allowed to be used by others?
> > > - if so it can result in other hard-to-catch bugs
> > 
> > Yes, just like most other use-after-free from any other subsystem in the
> > kernel :)
> > 
> > The expectation is that such BUGs are found early during testing
> > (triggering a WARN) such that they can be fixed early.
> > 
> > But we could also report a bad page here and just stop (return false).
> 
> I think the WARN_ON_ONCE() makes the problematic situation detectable.
> However, if we should prevent the page from being used on the detection,
> sure, I can update the patch.

I will respin with the following diff folded on the top.

	Byungchul
---
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 01dd14123065..5ae55a5d7b5d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1377,7 +1377,10 @@ __always_inline bool free_pages_prepare(struct page *page,
 	}
 	if (unlikely(page_has_type(page))) {
 		/* networking expects to clear its page type before releasing */
-		WARN_ON_ONCE(PageNetpp(page));
+		if (unlikely(PageNetpp(page))) {
+			bad_page(page, "page_pool leak");
+			return false;
+		}
 		/* Reset the page_type (which overlays _mapcount) */
 		page->page_type = UINT_MAX;
 	}

> 
> Thanks,
> 	Byungchul
> 
> > 
> > --
> > Cheers
> > 
> > David