linux-kernel - [RFC PATCH 0/3] folio->mapping == NULL check issue

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

Message-ID: <20251120035953.1115736-1-ziy@nvidia.com>
Date: Wed, 19 Nov 2025 22:59:50 -0500
From: Zi Yan <ziy@...dia.com>
To: David Hildenbrand <david@...nel.org>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Zi Yan <ziy@...dia.com>,
	Baolin Wang <baolin.wang@...ux.alibaba.com>,
	"Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Nico Pache <npache@...hat.com>,
	Ryan Roberts <ryan.roberts@....com>,
	Dev Jain <dev.jain@....com>,
	Barry Song <baohua@...nel.org>,
	Lance Yang <lance.yang@...ux.dev>,
	Miaohe Lin <linmiaohe@...wei.com>,
	Naoya Horiguchi <nao.horiguchi@...il.com>,
	linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: [RFC PATCH 0/3] folio->mapping == NULL check issue

Hi all,

Based on Wei's observation[1], this patchset is trying to solve several
potential issues:
1. Patch 1, 2: dereferencing NULL folio->mapping in
   try_folio_split_to_order() for future users,
2. Patch 3: improper handling of negative return value of
   min_order_for_split() in mm/memory-failure.c

No bug is present for the existing code.

For 1, try_folio_split_to_order() is used in
truncate_inode_partial_folio() and it is fine since folio->mapping is
always not NULL there.

For 2, mm/memory-failure.c code does not check for -EBUSY return value of
min_order_for_split() and directly passes it to a folio split function.
The code works by accident but needs to be fixed.

folio_split_supported() does not check if folio->mapping is NULL, but
can dereference it in some cases. My current fix is adding a kernel-doc
to clarify this requirement. An alternative is to add folio->mapping
check and return -EBUSY and return -EINVAL for the other checks. But
folio_split_supported() will no longer checks for "supported",
folio_split_can_split() might be a better name. Then, the existing
can_split_folio() might better be renamed to
folio_split_refcount_check(). In addition, try_folio_split_to_order(),
which calls folio_split_supported(), might want to handle -EBUSY separately
to avoid calling split_huge_page_to_order() when the folio is truncated
for a known -EBUSY error.

Let me know your thoughts. Thanks.

Link: https://lore.kernel.org/all/20251120004735.52z7r4xmogw7mbsj@master/ [1]

Zi Yan (3):
  mm/huge_memory: prevent NULL pointer dereference in
    try_folio_split_to_order()
  mm/huge_memory: add kernel-doc for folio_split_supported()
  mm/memory-failure: handle min_order_for_split() error code properly

 include/linux/huge_mm.h |  7 +++++++
 mm/huge_memory.c        | 17 +++++++++++++++++
 mm/memory-failure.c     |  8 ++++++--
 3 files changed, 30 insertions(+), 2 deletions(-)

-- 
2.51.0