Skip to content

Commit 894f99e

Browse files
zambboakpm00
authored andcommitted
mm/vma: fix memory leak in __mmap_region()
commit 605f658 ("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: <TASK> 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 </TASK> 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. Link: https://lkml.kernel.org/r/[email protected] Fixes: 605f658 ("mm/vma: do not leak memory when .mmap_prepare swaps the file") Signed-off-by: Sechang Lim <[email protected]> Reviewed-by: Lorenzo Stoakes (Oracle) <[email protected]> Acked-by: Vlastimil Babka (SUSE) <[email protected]> Cc: Jann Horn <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Lorenzo Stoakes (Oracle) <[email protected]> Cc: Pedro Falcato <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
1 parent 2ecbe06 commit 894f99e

1 file changed

Lines changed: 7 additions & 0 deletions

File tree

mm/vma.c

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2781,6 +2781,13 @@ static unsigned long __mmap_region(struct file *file, unsigned long addr,
27812781
if (map.charged)
27822782
vm_unacct_memory(map.charged);
27832783
abort_munmap:
2784+
/*
2785+
* This indicates that .mmap_prepare has set a new file, differing from
2786+
* desc->vm_file. But since we're aborting the operation, only the
2787+
* original file will be cleaned up. Ensure we clean up both.
2788+
*/
2789+
if (map.file_doesnt_need_get)
2790+
fput(map.file);
27842791
vms_abort_munmap_vmas(&map.vms, &map.mas_detach);
27852792
return error;
27862793
}

0 commit comments

Comments
 (0)