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 50F4D442390; Mon, 17 Aug 2026 14:16:13 +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=1786976174; cv=none; b=Ha8l7KeoT6lOhbrFCoJkt2vwX8cDp/7jZ4jt/plyVgTVdTQ63eo/6AJN8NK2g1HMEOwJHHTDWBD+6F90DPSuRD1teVy2mh3q4N6/2NalJ5BUyr74GJ0DaN8pOiEsAZ5wzYlMKJwgD30Q9hDzV1+Xrlqxv1/H2N05MS1FmK/x0hI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786976174; c=relaxed/simple; bh=+bOQvvRYL54iLs+JH+/JFvXh8B3pcn1/BKe1lFEbpkY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RnwTWyVJv3gbMwQPzEpt5jkJUbT2/kY6iVxEFb6Hu7b8fNT/jCzeb7btOlyEcT2f2ATRa4BMe6s8Ce1/LpybD4d6CPaKNaRUJ2JP17cwjkNJrDKCYdMn6vSfpMgcaAv5vHoICcg2V1KVBrxVPQuthkFPiEBVk9Cq0T1Secpjl0k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=agBW+3Ya; 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="agBW+3Ya" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 999D71F000E9; Mon, 17 Aug 2026 14:16:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1786976173; bh=76UEaVw13QNGW0qWQH+udo2g3c2y0qKpC8wtrVxUDDY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=agBW+3YaAJtREnS7eHmgmrMRUydFkEeeWZg1XNAJNQ5+hgoTREwli3Cj5vGV3h5F1 DvN8TVEdVWu0ePCevmpobfKM4YsMc5TPhdd1Afp164kRLOxsgDIfLVZ6LJBSyvJzhH X/P8ll0w5jOJVCQlfdXY3hAPkYHpWRIkMhRVQYlY= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Xiangfeng Cai , Muchun Song , Baoquan He , David Hildenbrand , Oscar Salvador , Shuah Khan , Wei Yang , Andrew Morton Subject: [PATCH 5.10 243/389] mm/hugetlb: fix list corruption in allocate_file_region_entries() Date: Mon, 17 Aug 2026 15:31:22 +0200 Message-ID: <20260817132548.768826788@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260817132538.796021292@linuxfoundation.org> References: <20260817132538.796021292@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 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Xiangfeng Cai commit dd9623f58ec702a07b2d67179d6fcea79c52231a upstream. allocate_file_region_entries() tops up resv->region_cache with freshly allocated file_region descriptors. The allocation uses GFP_KERNEL, so resv->lock is dropped around it: the new entries are gathered on a stack-local list head, allocated_regions, and spliced into resv->region_cache once the lock is re-acquired. The splice used list_splice(), which moves the entries but does not re-initialize the source head, so allocated_regions is left pointing at an entry that now lives on resv->region_cache. The top-up runs in a while loop that re-checks the cache deficit after re-acquiring the lock. For a shared mapping the resv_map is shared by every mapper of the hugetlbfs inode, so a concurrent region_chg()/region_add()/region_del() on the same resv_map can consume cache entries during the unlocked window and force a second iteration. That iteration calls list_add() on the stale head and corrupts the list; with CONFIG_DEBUG_LIST the __list_add_valid() check trips: list_add corruption. next->prev should be prev (ffffc900011ff7f8), but was ffff88814c281460. (next=ffff88814c545640). kernel BUG at lib/list_debug.c:31! allocate_file_region_entries+0x191/0x420 region_chg+0x267/0x300 hugetlb_reserve_pages+0x387/0xc80 hugetlbfs_file_mmap+0x2ce/0x3f0 mmap_region+0x1348/0x1a80 do_mmap+0x85e/0xb90 vm_mmap_pgoff+0x18c/0x330 ksys_mmap_pgoff+0x2a1/0x3e0 do_syscall_64+0xd7/0x420 Without CONFIG_DEBUG_LIST the bad list_add() silently links a kernel-stack address into resv->region_cache, leading to later use-after-free. This was observed as a real host panic on a dense KVM host where a QEMU guest-RAM hugetlbfs file was mapped MAP_SHARED by both QEMU and a separate SPDK/DPDK vhost-user target, generating concurrent region_* traffic on one shared resv_map. Use list_splice_init() so the source head is re-initialized empty after each splice, making the retry loop safe. Link: https://lore.kernel.org/20260713171456.300518-2-caixiangfeng@bytedance.com Fixes: d3ec7b6e09e5 ("mm/hugetlb: use list_splice to merge two list at once") Signed-off-by: Xiangfeng Cai Reviewed-by: Muchun Song Cc: Baoquan He Cc: David Hildenbrand Cc: Oscar Salvador Cc: Shuah Khan Cc: Wei Yang Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- mm/hugetlb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -482,7 +482,7 @@ static int allocate_file_region_entries( spin_lock(&resv->lock); - list_splice(&allocated_regions, &resv->region_cache); + list_splice_init(&allocated_regions, &resv->region_cache); resv->region_cache_count += to_allocate; }