netdev - Re: [PATCH][RESEND][RFC] Fix 32-bit boot failure due inaccurate page_pool_page_is

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <7e48c00a-5273-4de1-a2b6-8c122127160b@kernel.org>
Date: Mon, 15 Sep 2025 11:45:18 +0200
From: Jesper Dangaard Brouer <hawk@...nel.org>
To: Helge Deller <deller@...nel.org>, David Hildenbrand <david@...hat.com>,
 Toke Høiland-Jørgensen <toke@...hat.com>,
 Ilias Apalodimas <ilias.apalodimas@...aro.org>,
 "David S. Miller" <davem@...emloft.net>,
 Linux Memory Management List <linux-mm@...ck.org>, netdev@...r.kernel.org,
 Linux parisc List <linux-parisc@...r.kernel.org>,
 Andrew Morton <akpm@...ux-foundation.org>
Cc: Mina Almasry <almasrymina@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Toke Høiland-Jørgensen <toke@...nel.org>
Subject: Re: [PATCH][RESEND][RFC] Fix 32-bit boot failure due inaccurate
 page_pool_page_is_pp()

On 13/09/2025 01.06, Helge Deller wrote:
> Commit ee62ce7a1d90 ("page_pool: Track DMA-mapped pages and unmap them when
> destroying the pool") changed PP_MAGIC_MASK from 0xFFFFFFFC to 0xc000007c on
> 32-bit platforms.
> 
> The function page_pool_page_is_pp() uses PP_MAGIC_MASK to identify page pool
> pages, but the remaining bits are not sufficient to unambiguously identify
> such pages any longer.
> 

Function netmem_is_pp[1] uses same kind of check against PP_MAGIC_MASK.
The call-site skb_pp_recycle[2] is protected by skb->pp_recycle check.

BUT napi_pp_put_page[3] callers have been expanded, and I'm uncertain if
they will be affected by this. (Cc Mina)

  [1] 
https://elixir.bootlin.com/linux/v6.16.7/source/net/core/netmem_priv.h#L23-L26
  [2] 
https://elixir.bootlin.com/linux/v6.16.7/source/net/core/skbuff.c#L1009
  [3] 
https://elixir.bootlin.com/linux/v6.16.7/source/net/core/skbuff.c#L991-L995

> So page_pool_page_is_pp() now sometimes wrongly reports pages as page pool
> pages and as such triggers a kernel BUG as it believes it found a page pool
> leak.
> 

This sounds scary to me, as netstack (see above code examples) also uses
checks against PP_MAGIC_MASK (+ PP_SIGNATURE).  I hope these checks
isn't also subject to this issue(!?)

(To Toke:) Did we steal too many bits for PP_DMA_INDEX_MASK?

> There are patches upcoming where page_pool_page_is_pp() will not depend on
> PP_MAGIC_MASK and instead use page flags to identify page pool pages. Until
> those patches are merged, the easiest temporary fix is to disable the check
> on 32-bit platforms.
> 
> Cc: Jesper Dangaard Brouer <hawk@...nel.org>
> Cc: Ilias Apalodimas <ilias.apalodimas@...aro.org>
> Cc: David Hildenbrand <david@...hat.com>
> Acked-by: David Hildenbrand <david@...hat.com>
> Cc: Toke Høiland-Jørgensen <toke@...hat.com>
> Cc: Linux Memory Management List <linux-mm@...ck.org>
> Cc: netdev@...r.kernel.org
> Cc: Linux parisc List <linux-parisc@...r.kernel.org>
> Cc: <stable@...r.kernel.org> # v6.15+
> Signed-off-by: Helge Deller <deller@....de>
> Link: https://www.spinics.net/lists/kernel/msg5849623.html
> Fixes: ee62ce7a1d90 ("page_pool: Track DMA-mapped pages and unmap them when destroying the pool")
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 1ae97a0b8ec7..f3822ae70a81 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -4190,7 +4190,7 @@ int arch_lock_shadow_stack_status(struct task_struct *t, unsigned long status);
>    */
>   #define PP_MAGIC_MASK ~(PP_DMA_INDEX_MASK | 0x3UL)
>   
> -#ifdef CONFIG_PAGE_POOL
> +#if defined(CONFIG_PAGE_POOL) && defined(CONFIG_64BIT)
>   static inline bool page_pool_page_is_pp(const struct page *page)
>   {
>   	treturn (page->pp_magic & PP_MAGIC_MASK) == PP_SIGNATURE;
> 
> ----- End forwarded message -----

Looks like your email got truncated.
--Jesper