From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4E0AF3B9943; Fri, 7 Aug 2026 14:55:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786114509; cv=none; b=aPnKHpZxhttwVHIiUkw0XmJtIzjutiHlanr4+Evg0YFsXJgL6ziq08i9nKn31ewRELJNlLZh5zFW+AS1CX3mKaBtVkqd4vheJXxKDaXTMZxwPgFIhl/7tJhKBb59M49P83vHgGsSox6G4msYsDv0wL/DFFjgZaiccCuuyzLUu94= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786114509; c=relaxed/simple; bh=SQi9ehetMBtNssfnFt5emLpzeRkJuVyifyGT3mfqor8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RJsUBAXrTwbdJa6uf4j9wKUNmGSEntBDc/vCydve4ggKPCmwoRxr5+C0bvTFZ5mGyQN7vZM/bEC4/kB8ef+W3q4QcxttPJ1++hfioxWVdtLch8QI5zsZy8Wnn2TCg+YOxWVdQ7Z0tgeitxQgLHWGCl+/SO3psLuZtCRRtQL+cKU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=yQS/+j7t; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="yQS/+j7t" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4F381F000E9; Fri, 7 Aug 2026 14:55:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1786114504; bh=+lXJbukKgrQmwYO/GuTxFZljdNHfFNZPeqTfRcZaqG4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=yQS/+j7t76I7Uk8ZwcZdlOISPOaXxLPCWRaiD4Y82sYkhZTw1eRKdaxx/iQxQXxIg DX/xxlLDwCpPsobSqnupnX3i2Kg4B2LQcjl3v1AZkRftp6zT8MMDQAd3zlT1WNsnzB IzoR58reXWo/e/wEblarhGJr+PY2gzCKb4gI9MGo= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, "Kiryl Shutsemau (Meta)" , Hao Zhang , "David Hildenbrand (Arm)" , Zi Yan , Baolin Wang , Miaohe Lin , Barry Song , Dev Jain , Lance Yang , "Liam R. Howlett" , Lorenzo Stoakes , Naoya Horiguchi , Nico Pache , Ryan Roberts , Andrew Morton , Sasha Levin Subject: [PATCH 6.12 287/337] mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios Date: Fri, 7 Aug 2026 16:38:10 +0200 Message-ID: <20260807143424.754806656@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260807143418.516897842@linuxfoundation.org> References: <20260807143418.516897842@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Kiryl Shutsemau (Meta) [ Upstream commit e923bd21058ea02fd0dcd3549d151d143fd036e5 ] __folio_split() keeps dereferencing the mapping after the split: shmem_uncharge(mapping->host) and remap_page() while the folios are still frozen/locked, and i_mmap_unlock_read(mapping) at the very end, after the after-split folios have been unlocked and freed. Nothing holds an inode reference across that. The split relies on @folio -- which the beyond-EOF drop loop never removes, as it starts at folio_next(folio) -- staying locked and in the page cache to hold off eviction. But the unlock loop unlocks @folio before i_mmap_unlock_read() runs. If the caller's @lock_at is a tail beyond EOF, as memory_failure() passes when splitting a poisoned tail of a shmem THP that reaches past i_size during truncation, it too is gone from the page cache; so once @folio is unlocked no locked, in-cache folio pins the inode, and a concurrent final iput() can evict and RCU-free it before i_mmap_unlock_read() touches i_mmap_rwsem: BUG: KASAN: slab-use-after-free in __up_read+0x634/0x790 i_mmap_unlock_read include/linux/fs.h:537 [inline] __folio_split+0x732/0x1640 mm/huge_memory.c:4100 try_to_split_thp_page+0xab/0x390 mm/memory-failure.c:1675 memory_failure+0x1394/0x26e0 mm/memory-failure.c:2470 Freed by task 4601: shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c:5177 evict+0x57f/0xac0 fs/inode.c:870 Do every mapping dereference while @folio still pins the inode: drop i_mmap_rwsem right after remap_page(), before the loop that unlocks and frees the after-split folios, and clear @mapping so the exit path does not unlock it again. shmem_uncharge() and remap_page() already run before that point, so after this nothing past the unlock loop touches the inode or the mapping. This is now a rule the split depends on, alongside keeping @folio frozen until the page cache is updated: no inode or mapping dereference once the after-split folios start being unlocked. Link: https://lore.kernel.org/20260716095424.471052-1-kirill@shutemov.name Fixes: baa355fd3314 ("thp: file pages support for split_huge_page()") Signed-off-by: Kiryl Shutsemau (Meta) Reported-by: Hao Zhang Closes: https://lore.kernel.org/linux-mm/20260710071344.GA106129@zh-pc Co-developed-by: Hao Zhang Signed-off-by: Hao Zhang Acked-by: David Hildenbrand (Arm) Reviewed-by: Zi Yan Reviewed-by: Baolin Wang Reviewed-by: Miaohe Lin Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Naoya Horiguchi Cc: Nico Pache Cc: Ryan Roberts Cc: Signed-off-by: Andrew Morton (cherry picked from commit e923bd21058ea02fd0dcd3549d151d143fd036e5) [ kas: adapt to the __split_huge_page()/split_huge_page_to_list_to_order() two-function split: pass @mapping into __split_huge_page() and drop it there, before the loop that frees the after-split subpages while the head is still locked; the caller then skips its own i_mmap unlock ] Signed-off-by: Kiryl Shutsemau (Meta) Signed-off-by: Sasha Levin --- mm/huge_memory.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index e60c21b924644..b2daa1767d900 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -3206,7 +3206,7 @@ static void __split_huge_page_tail(struct folio *folio, int tail, } static void __split_huge_page(struct page *page, struct list_head *list, - pgoff_t end, unsigned int new_order) + pgoff_t end, unsigned int new_order, struct address_space *mapping) { struct folio *folio = page_folio(page); /* Scan poisoned pages when split a poisoned folio to large folios */ @@ -3303,6 +3303,16 @@ static void __split_huge_page(struct page *page, struct list_head *list, if (new_order) page = compound_head(page); + /* + * Drop the mapping while the head page is still locked and thus pins + * the inode. The loop below may free the after-split subpages -- + * including the head, when @page is a tail beyond EOF that the split + * dropped from the page cache -- which could otherwise let the inode, + * and @mapping, be freed before this unlock. + */ + if (mapping) + i_mmap_unlock_read(mapping); + for (i = 0; i < nr; i += new_nr) { struct page *subpage = head + i; struct folio *new_folio = page_folio(subpage); @@ -3580,7 +3590,9 @@ int split_huge_page_to_list_to_order(struct page *page, struct list_head *list, mod_mthp_stat(order, MTHP_STAT_NR_ANON, -1); mod_mthp_stat(new_order, MTHP_STAT_NR_ANON, 1 << (order - new_order)); } - __split_huge_page(page, list, end, new_order); + __split_huge_page(page, list, end, new_order, mapping); + /* __split_huge_page() dropped the i_mmap lock */ + mapping = NULL; ret = 0; } else { spin_unlock(&ds_queue->split_queue_lock); -- 2.53.0