Re: [PATCH] mmap: Fix copy_vma() failure path

[Lukas Bulwahn <lukas.bulwahn@gmail.com>]

On Tue, Oct 11, 2022 at 10:36 PM Liam Howlett <liam.howlett@oracle.com> wrote:
>
> The anon vma was not unlinked and the file was not closed in the failure
> path when the machine runs out of memory during the maple tree
> modification.  This caused a memory leak of the anon vma chain and vma
> since neither would be freed.
>
> Reported-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
> Fixes: 524e00b36e8c (mm: remove rb tree.)
> Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
> ---

Here my detailed test report:

First, I ran the reproducer
https://elisa-builder-00.iol.unh.edu/syzkaller-next/report?id=3113810b9abd3dfeb581759df93d3171d1a90f18
on the latest commit from Linus' tree, i.e., commit 49da07006239.
This resulted in the following kernel crash report on x86_64 defconfig
+ syzkaller-recommended debug features:

[  632.446911] kmemleak: 2 new suspected memory leaks (see
/sys/kernel/debug/kmemleak)
[  642.194797] kmemleak: 2 new suspected memory leaks (see
/sys/kernel/debug/kmemleak)

BUG: memory leak
unreferenced object 0xffff88800eab3220 (size 208):
  comm "a.out", pid 411, jiffies 4295289355 (age 20.054s)
  hex dump (first 32 bytes):
    20 32 ab 0e 80 88 ff ff 00 00 00 00 00 00 00 00   2..............
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<000000006344da94>] __anon_vma_prepare+0x288/0x520
    [<0000000079cb6e3d>] __handle_mm_fault+0x1672/0x1a90
    [<000000003165d13e>] handle_mm_fault+0x177/0x520
    [<00000000d502ed60>] __get_user_pages+0x696/0x13b0
    [<000000000c44f161>] populate_vma_page_range+0x242/0x320
    [<00000000429a417a>] __mm_populate+0x1c6/0x3b0
    [<00000000988f9924>] do_mlock+0x3ad/0x6f0
    [<0000000099ba0e21>] __x64_sys_mlock2+0xba/0x100
    [<00000000a302ea0e>] do_syscall_64+0x3a/0x90
    [<0000000069487f88>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

BUG: memory leak
unreferenced object 0xffff88800ef27ba0 (size 64):
  comm "a.out", pid 411, jiffies 4295289357 (age 20.053s)
  hex dump (first 32 bytes):
    30 3c 94 09 80 88 ff ff 20 32 ab 0e 80 88 ff ff  0<...... 2......
    78 3c 94 09 80 88 ff ff 78 3c 94 09 80 88 ff ff  x<......x<......
  backtrace:
    [<00000000ecf2fb6f>] anon_vma_clone+0xd3/0x590
    [<00000000e1cdd897>] copy_vma+0x3ea/0x7f0
    [<00000000ef59b15d>] move_vma.isra.48+0x8e6/0xf40
    [<00000000cf84e8ba>] mremap_to.isra.49+0x4d0/0x6c0
    [<00000000cf08a1f8>] __x64_sys_mremap+0x9cc/0xf20
    [<00000000a302ea0e>] do_syscall_64+0x3a/0x90
    [<0000000069487f88>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

BUG: memory leak
unreferenced object 0xffff88800df86330 (size 208):
  comm "a.out", pid 412, jiffies 4295296993 (age 12.417s)
  hex dump (first 32 bytes):
    30 63 f8 0d 80 88 ff ff 00 00 00 00 00 00 00 00  0c..............
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<000000006344da94>] __anon_vma_prepare+0x288/0x520
    [<0000000079cb6e3d>] __handle_mm_fault+0x1672/0x1a90
    [<000000003165d13e>] handle_mm_fault+0x177/0x520
    [<00000000d502ed60>] __get_user_pages+0x696/0x13b0
    [<000000000c44f161>] populate_vma_page_range+0x242/0x320
    [<00000000429a417a>] __mm_populate+0x1c6/0x3b0
    [<00000000988f9924>] do_mlock+0x3ad/0x6f0
    [<0000000099ba0e21>] __x64_sys_mlock2+0xba/0x100
    [<00000000a302ea0e>] do_syscall_64+0x3a/0x90
    [<0000000069487f88>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

BUG: memory leak
unreferenced object 0xffff888015235180 (size 64):
  comm "a.out", pid 412, jiffies 4295296995 (age 12.415s)
  hex dump (first 32 bytes):
    00 fd 57 0d 80 88 ff ff 30 63 f8 0d 80 88 ff ff  ..W.....0c......
    48 fd 57 0d 80 88 ff ff 48 fd 57 0d 80 88 ff ff  H.W.....H.W.....
  backtrace:
    [<00000000ecf2fb6f>] anon_vma_clone+0xd3/0x590
    [<00000000e1cdd897>] copy_vma+0x3ea/0x7f0
    [<00000000ef59b15d>] move_vma.isra.48+0x8e6/0xf40
    [<00000000cf84e8ba>] mremap_to.isra.49+0x4d0/0x6c0
    [<00000000cf08a1f8>] __x64_sys_mremap+0x9cc/0xf20
    [<00000000a302ea0e>] do_syscall_64+0x3a/0x90
    [<0000000069487f88>] entry_SYSCALL_64_after_hwframe+0x63/0xcd


This is just as expected and as I reported it to Liam.

Then, I applied this patch here, rebuilt the kernel and re-ran the
reproducer. After roughly running the reproducer for 15 minutes, it
did not show any kernel crash report. So, the patch seems to have
solved the reported issue.

Tested-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>

Thanks, Liam.

Lukas