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 5564F1E9919 for ; Wed, 1 Apr 2026 18:44:27 +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=1775069067; cv=none; b=BH04ANQYm8kkgbxE2snt1DYSU4V59a0H0rJ4rR+8KtTpJQQOQUDQO87IjtJpk8VRLXhIm6TgqFen76qzof+PtQeEpQQ0PVyKBmCUDXKrwFf7D6ZHPe+7gTckmDB8vTuaFGjpBa/A2wu4fg++X3FZRb662f8EBTVmEtZkqAEeGjE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775069067; c=relaxed/simple; bh=7xzStj3k1oXqrTXPBH4aWe0qsaL6BGdKjHlWyPnNBpM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kApDDBtCRMsIfUhEd040N5FpyJzrgmlQp9zYFruTRhLP28Mp3E0maqiustuEGLx1e5NAq/JSX8nYT7JxThxQpe0pcbHq/oP0/6wQOaUoFPxno5nkB0HqeCG3kPUocuIOYcWa2B+3O0C+aJ1aOfpbUzSSu9bqN7ZsnGDHmjyv+Ww= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VD5vpqkI; 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="VD5vpqkI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6889FC4CEF7; Wed, 1 Apr 2026 18:44:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775069067; bh=7xzStj3k1oXqrTXPBH4aWe0qsaL6BGdKjHlWyPnNBpM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=VD5vpqkI6cuuDjGekS+PkL53/yMBQy0wk1mggFjtVnAxP2ACyj0GXCnydwAoS/Mt6 q1RGGKqSqNqDH01sZd651krrjf+Wv2RZYj1OjKNew/N/TQPGGttZD8g7uCyjlqPtQp trut2dUioke2w2pAwUsn2f1ycchEM3qwbr5M0VGsjhT3GM9H8SNamG0kYrrjPW4qEs fmYCthWdPr/k/yENJZ+zs6tExyzi6ZprP6+EW8TWRcF3pxxMqy+nHxeWby1oyxVAGa vcn4I4kbrtIaF30/U0TlFfU4RJweIDG+GWpiqeXBxuBiueeJkcz+td3Cc9lpPaaIqG xrqiYXqOnaXQQ== Message-ID: <61ef9256-01ea-49a4-9824-be1c3c1fcba5@kernel.org> Date: Wed, 1 Apr 2026 20:44:23 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] mm/vma: fix memory leak in __mmap_region() Content-Language: en-US To: Sechang Lim , Andrew Morton , "Liam R . Howlett" , Lorenzo Stoakes Cc: Jann Horn , Pedro Falcato , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260331180811.1333348-1-rhkrqnwk98@gmail.com> From: "Vlastimil Babka (SUSE)" In-Reply-To: <20260331180811.1333348-1-rhkrqnwk98@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/31/26 20:08, 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/0x420 > 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. > > Fixes: 605f6586ecf7 ("mm/vma: do not leak memory when .mmap_prepare swaps the file") > Reviewed-by: Lorenzo Stoakes (Oracle) > Signed-off-by: Sechang Lim Acked-by: Vlastimil Babka (SUSE) Thanks!