From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 DBCA9310651 for ; Tue, 31 Mar 2026 13:30:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774963812; cv=none; b=WtHD52fc1OiHqCGZkKRO7rO8e4vPcbfsXXCdxWaN/P/lkhMAZ9I9WtBYBxBpNIOKEJ4i8CQY8FCZfxYYLPAKDqd2Vsqb9V7oxTz3P5BAMLEIcSZn5cRWT3LC9vrm7nkEOxLqHVCeY0jghLvyn7HuNsS77LJh26tBGMp5q8SWUoI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774963812; c=relaxed/simple; bh=UeZZK6K4qJ6/l95AkoqbqsJOmBEmzy446L6mESN+wLE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BXzlcCkzE9H3d2q4xndlKhgSLtJymdF7NQjChC1Hcz34xg0/msxhqimjd3+Bsglfbexg+oCycZA9R9D+VN3QxM+e/zU934iZk7PoSZRxPxYcNioMProbtHBe6+ywF3JArleFRIXJg7c5ogTdXxQOa5zRUIcUmQswcZ7O0yNYu3A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lF4B6pby; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lF4B6pby" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E409AC19423; Tue, 31 Mar 2026 13:30:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774963812; bh=UeZZK6K4qJ6/l95AkoqbqsJOmBEmzy446L6mESN+wLE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lF4B6pbyVM6USIUyTtPDT54iNbFVWiTse/2OX2uSfDWt0j0aKV1JH0vjzEk3SpQQt 6nADLQAF0A+YQF+vuoHcv2gQP3rnG9uuwOFjGK6ORxvUYL78lBKOVYSDWFxhKY9/8L pOrOfYs05VxJ005QYMo+O2O+NMKCpF9BklAm2emaGpTyidMF9x5xBPBU5WCztz86IO 90y3lkWINYEUGeRq4SdPaZfzlWGkBIUBHJlamNt9e3Naia+FtEq+3ET7uAGUxRdJVw FUfzU/APYb0dI16oJ90Zgkw005LXteztjyB6hp7a8Nk9BMjiUHSLMDh0TtImIJ+zV/ xuEDPJ92W1VMQ== Date: Tue, 31 Mar 2026 14:30:09 +0100 From: "Lorenzo Stoakes (Oracle)" To: Sechang Lim Cc: Andrew Morton , "Liam R . Howlett" , Vlastimil Babka , Jann Horn , Pedro Falcato , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/vma: fix memory leak in __mmap_region() Message-ID: References: <20260331121906.1301155-1-rhkrqnwk98@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260331121906.1301155-1-rhkrqnwk98@gmail.com> On Tue, Mar 31, 2026 at 12:19:06PM +0000, Sechang Lim wrote: > commit 605f6586ecf7 ("mm/vma: do not leak memory when .mmap_prepare > swaps the file") handled the success path by skipping get_file() via > file_doesnt_need_get, but missed the error path. > > When /dev/zero is mmap'd with MAP_SHARED, mmap_zero_prepare() calls > shmem_zero_setup_desc() which allocates a new shmem file to back the > mapping. If __mmap_new_vma() subsequently fails, this replacement > file is never fput()'d - the original is released by > ksys_mmap_pgoff(), but nobody releases the new one. > > Add fput() for the swapped file in the error path. > > Reproducible with fault injection. > > FAULT_INJECTION: forcing a failure. > name failslab, interval 1, probability 0, space 0, times 1 > CPU: 2 UID: 0 PID: 366 Comm: syz.7.14 Not tainted 7.0.0-rc6 #2 PREEMPT(full) > Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 > Call Trace: > > dump_stack_lvl+0x164/0x1f0 > should_fail_ex+0x525/0x650 > should_failslab+0xdf/0x140 > kmem_cache_alloc_noprof+0x78/0x630 > vm_area_alloc+0x24/0x160 > __mmap_region+0xf6b/0x2660 > mmap_region+0x2eb/0x3a0 > do_mmap+0xc79/0x1240 > vm_mmap_pgoff+0x252/0x4c0 > ksys_mmap_pgoff+0xf8/0x120 > __x64_sys_mmap+0x12a/0x190 > do_syscall_64+0xa9/0x580 > entry_SYSCALL_64_after_hwframe+0x76/0x7e > > > kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak) > BUG: memory leak > unreferenced object 0xffff8881118aca80 (size 360): > comm "syz.7.14", pid 366, jiffies 4294913255 > hex dump (first 32 bytes): > 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... > ff ff ff ff ff ff ff ff c0 28 4d ae ff ff ff ff .........(M..... > backtrace (crc db0f53bc): > kmem_cache_alloc_noprof+0x3ab/0x630 > alloc_empty_file+0x5a/0x1e0 > alloc_file_pseudo+0x135/0x220 > __shmem_file_setup+0x274/0x42 > shmem_zero_setup_desc+0x9c/0x170 > mmap_zero_prepare+0x123/0x140 > __mmap_region+0xdda/0x2660 > mmap_region+0x2eb/0x3a0 > do_mmap+0xc79/0x1240 > vm_mmap_pgoff+0x252/0x4c0 > ksys_mmap_pgoff+0xf8/0x120 > __x64_sys_mmap+0x12a/0x190 > do_syscall_64+0xa9/0x580 > entry_SYSCALL_64_after_hwframe+0x76/0x7e > > Found by syzkaller. Which syzkaller, a private implementation? > > Fixes: 605f6586ecf7 ("mm/vma: do not leak memory when .mmap_prepare swaps the file") Probably don't need a cc: stable as we're at -rc6 and this is from 6.19. > Signed-off-by: Sechang Lim Logic looks correct to me, so: Reviewed-by: Lorenzo Stoakes (Oracle) But please adjust the logic as per the below and maybe respin for ease, where you can add my tag also. Thanks, Lorenzo > --- > mm/vma.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/mm/vma.c b/mm/vma.c > index be64f781a3aa..89073980de46 100644 > --- a/mm/vma.c > +++ b/mm/vma.c > @@ -2781,6 +2781,8 @@ static unsigned long __mmap_region(struct file *file, unsigned long addr, > if (map.charged) > vm_unacct_memory(map.charged); > abort_munmap: > + if (map.file_doesnt_need_get && map.file) Let's add a comment please. It would be broken to set map.file to NULL, so we don't need that check. Comment can be something like: /* * This indicates that .mmap_prepare has set a new file, differing from * desc->vm_file. But since we're aborting the operation, only the * original file will be cleaned up. Ensure we clean up both. */ if (map.file_doesnt_need_get) fput(map.file); > + fput(map.file); > vms_abort_munmap_vmas(&map.vms, &map.mas_detach); > return error; > } > -- > 2.43.0 >