From nobody Fri Jun 19 09:12:00 2026 Received: from zg8tmja5ljk3lje4ms43mwaa.icoremail.net (zg8tmja5ljk3lje4ms43mwaa.icoremail.net [209.97.181.73]) by smtp.subspace.kernel.org (Postfix) with ESMTP id EA5C3383C7F for ; Sat, 25 Apr 2026 07:07:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.97.181.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777100859; cv=none; b=al+mCDOelCJsXLcXKYfpqc85CTUbustaU8WPWkLYfYReaweZ3IRZpoutDe+12gBOKJhg4Mb0dcUDGp5/YsEKrKFaoO+cMQsWJz40pPgl1Wax/n24sovxWZ3xw5d3m8bDo5Ttu3t6eCq6TyaSlRxD9WKa259WOiNmNDXAwfP5VKM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777100859; c=relaxed/simple; bh=FE/CenTjKLL3dRauyeWdvyuTpH0V33SlCgvZE0R45fI=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=SmNUENih4wNi0rgW8ehHR1QrOMpotU0SgTVVsSRhwFVZzqoeb8VDDq8lDrLcSjeI8XrXsaIK8iAuERkNNsBDR1TMGqcSiQ6VhN006I4Q7hZbLCAY+56TZExym3VoB8Xj92zjV0JMle/66dbAVE5wxbuCtzM6MPtgUZIvY6cY2CQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=stu.xidian.edu.cn; spf=pass smtp.mailfrom=stu.xidian.edu.cn; dkim=fail (0-bit key) header.d=stu.xidian.edu.cn header.i=@stu.xidian.edu.cn header.b=u0CJDgFM reason="key not found in DNS"; arc=none smtp.client-ip=209.97.181.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=stu.xidian.edu.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=stu.xidian.edu.cn Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=stu.xidian.edu.cn header.i=@stu.xidian.edu.cn header.b="u0CJDgFM" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stu.xidian.edu.cn; s=dkim; h=Received:From:To:Cc:Subject:Date: Message-Id:MIME-Version:Content-Transfer-Encoding; bh=Wq+g7VMXuN 3cNKdQxZ/XBxYNAEgVEoQ0dq8X+4OPGLY=; b=u0CJDgFMk4XlIu2yAedGYJmku8 eytSrNL8+QuuTsh3bP6gavj9cci5OJjC3reD+lGfm+pOmr9qsU2hLqfVrqYHIinU SLi1o+KParn9KF0DC+iWZwF+WHzH5ZRAHLYQMkvTXyVpR8hHq0voLJgiSOqmeT3k 0mTw25to/rZdAtN8w= Received: from wmy.localdomain (unknown [113.200.174.100]) by hzbj-edu-front-3.icoremail.net (Coremail) with SMTP id BbQMCkAWNjAXaOxpxp7AAQ--.17089S2; Sat, 25 Apr 2026 15:07:13 +0800 (CST) From: Mingyu Wang <25181214217@stu.xidian.edu.cn> To: muchun.song@linux.dev Cc: Liam.Howlett@oracle.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mingyu Wang <25181214217@stu.xidian.edu.cn> Subject: [RFC PATCH] mm/hugetlb: fix resv_map memory leak in __mmap_region error path Date: Sat, 25 Apr 2026 15:07:00 +0800 Message-Id: <20260425070700.562229-1-25181214217@stu.xidian.edu.cn> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: BbQMCkAWNjAXaOxpxp7AAQ--.17089S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWFWxCF1UCFy5tFy5Zr15XFb_yoWrGr47pF s8Ww45Gr4kJ3sI9ws7Aw4DXr1Ykrs2gFWUKryrKw4fXrW3G3Z2kF4rXFWjvr45Ars2v3W2 vr4j93y7X3WjvFDanT9S1TB71UUUUUDqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9C14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26r1j6r1xM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r1j 6r4UM28EF7xvwVC2z280aVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVCY1x0267AKxVW8Jr 0_Cr1UM2vYz4IE04k24VAvwVAKI4IrM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAC Y4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJV W8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI2 0VAGYxC7MxkF7I0En4kS14v26r4a6rW5MxkIecxEwVAFwVW8CwCF04k20xvY0x0EwIxGrw CFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE 14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2 IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxK x2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI 0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x0pRwXocUUUUU= X-CM-SenderInfo: qsvrmiqsrujiux6v33wo0lvxldqovvfxof0/1tbiAQUOEWnriVmBUwABsa Content-Type: text/plain; charset="utf-8" While fuzzing with Syzkaller and fault injection (failslab) enabled, I observed a persistent resv_map memory leak in the hugetlb mmap error path. BUG: memory leak unreferenced object 0xffff888110b92400 (size 512): comm "syz.0.5386", pid 20390, jiffies 4298157188 backtrace: __kmalloc_cache_noprof+0x509/0x6e0 resv_map_alloc+0x47/0x3a0 hugetlb_reserve_pages+0x758/0x1220 hugetlbfs_file_mmap_prepare+0x492/0x790 __mmap_region+0x1ae6/0x29f0 This is a regression introduced by the recent VMA iterator and mmap region refactoring, which decoupled mmap preparation from VMA completion. In `__mmap_region()`, `call_mmap_prepare()` triggers `hugetlbfs_file_mmap_p= repare()`, which successfully allocates the `resv_map` and registers a `success_hook` in `desc->action`. If `__mmap_new_vma()` subsequently fails (e.g., `vma_iter_prealloc()` returns -ENOMEM due to failslab), the code jumps to `abort_munmap`. However, the `desc` structure is completely discarded without invoking any cleanup. The newly allocated empty VMA is freed, but since `set_vma_user_defined_fields()` was never reached, `vm_area_free()` doesn't call `hugetlb_vm_close()`. Thus, the `resv_map` is permanently leak= ed. This RFC proposes adding an `abort_hook` to `struct mmap_action` so that subsystems can properly clean up resources allocated during the `mmap_prepare` phase if VMA creation fails. Any feedback on whether this architectural approach is correct, or how to=20 properly implement the hugetlb unreserve rollback, would be highly apprecia= ted. Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> --- fs/hugetlbfs/inode.c | 9 +++++++++ include/linux/mm_types.h | 2 ++ mm/vma.c | 4 ++++ 3 files changed, 15 insertions(+) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 8b05bec08e04..002bb6d9ca23 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -102,6 +102,14 @@ static int hugetlb_file_mmap_prepare_success(const str= uct vm_area_struct *vma) return hugetlb_vma_lock_alloc((struct vm_area_struct *)vma); } =20 +static void hugetlb_file_mmap_prepare_abort(struct vm_area_desc *desc) +{ + /* + * TODO: Implement the proper rollback for hugetlb_reserve_pages() + * and drop the resv_map reference held in the desc here. + */ +} + static int hugetlbfs_file_mmap_prepare(struct vm_area_desc *desc) { struct file *file =3D desc->file; @@ -172,6 +180,7 @@ static int hugetlbfs_file_mmap_prepare(struct vm_area_d= esc *desc) if (!ret) { /* Allocate the VMA lock after we set it up. */ desc->action.success_hook =3D hugetlb_file_mmap_prepare_success; + desc->action.abort_hook =3D hugetlb_file_mmap_prepare_abort; /* * We cannot permit the rmap finding this VMA in the time * between the VMA being inserted into the VMA tree and the diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h index a308e2c23b82..9320f6699fa9 100644 --- a/include/linux/mm_types.h +++ b/include/linux/mm_types.h @@ -861,6 +861,8 @@ struct mmap_action { * it is not valid to clear the error here. */ int (*error_hook)(int err); +=09 + void (*abort_hook)(struct vm_area_desc *desc); =20 /* * This should be set in rare instances where the operation required diff --git a/mm/vma.c b/mm/vma.c index 377321b48734..d64cea5b4335 100644 --- a/mm/vma.c +++ b/mm/vma.c @@ -2799,6 +2799,10 @@ static unsigned long __mmap_region(struct file *file= , unsigned long addr, */ if (map.file_doesnt_need_get) fput(map.file); +=09 + if (have_mmap_prepare && desc.action.abort_hook) + desc.action.abort_hook(&desc); +=09 vms_abort_munmap_vmas(&map.vms, &map.mas_detach); return error; } --=20 2.34.1