Observed recent memory leak in __anon_vma_prepare

Observed recent memory leak in __anon_vma_prepare

[Lukas Bulwahn]

Dear Liam, dear Matthew, dear all,

The reproducer for the 'memory leak in __anon_vma_prepare' bug (see
https://elisa-builder-00.iol.unh.edu/syzkaller-next/report?id=3113810b9abd3dfeb581759df93d3171d1a90f18)
is reproducible, it is triggering the memory leak on the current
mainline (commit 60bb8154d1d7), and it was not triggering on v6.0. My
build config is a x86_64 defconfig.

My git bisection showed that:

524e00b36e8c547f5582eef3fb645a8d9fc5e3df is the first bad commit
commit 524e00b36e8c547f5582eef3fb645a8d9fc5e3df
Author: Liam R. Howlett <Liam.Howlett@Oracle.com>
Date:   Tue Sep 6 19:48:48 2022 +0000

The git bisect log is below, note that the commits 7fdbd37da5c6,
d0cf3dd47f0d and 0c563f148043 are marked good in the git bisect as
they caused bugs "BUG: Bad rss-counter state mm: ... type:MM_ANONPAGES
val:2". This bug report might have overshadowed the actual issue, and
hence the bug might have been introduced earlier, but was only visible
once the Bad rss-counter state bug disappeared.


git bisect start
# bad: [60bb8154d1d77042a5d43d335a68fdb202302cbe] Merge tag
'xfs-6.1-for-linus' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
git bisect bad 60bb8154d1d77042a5d43d335a68fdb202302cbe
# good: [4fe89d07dcc2804c8b562f6c7896a45643d34b2f] Linux 6.0
git bisect good 4fe89d07dcc2804c8b562f6c7896a45643d34b2f
# good: [ff6862c23d2e83d12d1759bf4337d41248fb4dc8] Merge tag
'arm-drivers-6.1' of
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
git bisect good ff6862c23d2e83d12d1759bf4337d41248fb4dc8
# good: [e8bc52cb8df80c31c73c726ab58ea9746e9ff734] Merge tag
'driver-core-6.1-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
git bisect good e8bc52cb8df80c31c73c726ab58ea9746e9ff734
# good: [4899a36f91a9f9b06878471096bd143e7253006d] Merge tag
'powerpc-6.1-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
git bisect good 4899a36f91a9f9b06878471096bd143e7253006d
# good: [0e0073eb1b60f4ec6faecea034a6772fe1409a88] Merge tag
'hyperv-next-signed-20221009' of
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux
git bisect good 0e0073eb1b60f4ec6faecea034a6772fe1409a88
# bad: [2f3568017268fc34eb0b6b4b3163c0f2e619fde6] kasan: move
kasan_get_*_meta to generic.c
git bisect bad 2f3568017268fc34eb0b6b4b3163c0f2e619fde6
# good: [354ed597442952fb680c9cafc7e4eb8a76f9514c] mm: multi-gen LRU:
kill switch
git bisect good 354ed597442952fb680c9cafc7e4eb8a76f9514c
# bad: [b3541d912a84dc40cabb516f2deeac9ae6fa30da] mm: delete unused
MMF_OOM_VICTIM flag
git bisect bad b3541d912a84dc40cabb516f2deeac9ae6fa30da
# bad: [67e7c16764c3cbf84a57d441fba3474217ac08d6] mm/mmap: change
do_brk_munmap() to use do_mas_align_munmap()
git bisect bad 67e7c16764c3cbf84a57d441fba3474217ac08d6
# good: [e15e06a8392321a19d8ebdbdd7643b7fa8874c17]
lib/test_maple_tree: add testing for maple tree
git bisect good e15e06a8392321a19d8ebdbdd7643b7fa8874c17
# bad: [3b0e81a1cdc9afbddb0543d08e38edb4e33c4baf] mmap: change zeroing
of maple tree in __vma_adjust()
git bisect bad 3b0e81a1cdc9afbddb0543d08e38edb4e33c4baf
# good: [7fdbd37da5c6ff002dc6d15e89a7708c2df4928e] mm/mmap: use the
maple tree for find_vma_prev() instead of the rbtree
git bisect good 7fdbd37da5c6ff002dc6d15e89a7708c2df4928e
# good: [d0cf3dd47f0d5d3bc366063f455215b99b06d62b] damon: convert
__damon_va_three_regions to use the VMA iterator
git bisect good d0cf3dd47f0d5d3bc366063f455215b99b06d62b
# bad: [524e00b36e8c547f5582eef3fb645a8d9fc5e3df] mm: remove rb tree.
git bisect bad 524e00b36e8c547f5582eef3fb645a8d9fc5e3df
# good: [0c563f148043569c81724ee0f9c5bad5a36b115a] proc: remove VMA
rbtree use from nommu
git bisect good 0c563f148043569c81724ee0f9c5bad5a36b115a
# first bad commit: [524e00b36e8c547f5582eef3fb645a8d9fc5e3df] mm:
remove rb tree.


If there is more information needed or other bisection to be done,
please let me know.

Best regards,

Lukas

Re: Observed recent memory leak in __anon_vma_prepare

[Liam Howlett]

* Lukas Bulwahn <lukas.bulwahn@gmail.com> [221011 12:35]:
> Dear Liam, dear Matthew, dear all,
> 
> The reproducer for the 'memory leak in __anon_vma_prepare' bug (see
> https://elisa-builder-00.iol.unh.edu/syzkaller-next/report?id=3113810b9abd3dfeb581759df93d3171d1a90f18)
> is reproducible, it is triggering the memory leak on the current
> mainline (commit 60bb8154d1d7), and it was not triggering on v6.0. My
> build config is a x86_64 defconfig.
> 
> My git bisection showed that:
> 
> 524e00b36e8c547f5582eef3fb645a8d9fc5e3df is the first bad commit
> commit 524e00b36e8c547f5582eef3fb645a8d9fc5e3df
> Author: Liam R. Howlett <Liam.Howlett@Oracle.com>
> Date:   Tue Sep 6 19:48:48 2022 +0000
> 
> The git bisect log is below, note that the commits 7fdbd37da5c6,
> d0cf3dd47f0d and 0c563f148043 are marked good in the git bisect as
> they caused bugs "BUG: Bad rss-counter state mm: ... type:MM_ANONPAGES
> val:2". This bug report might have overshadowed the actual issue, and
> hence the bug might have been introduced earlier, but was only visible
> once the Bad rss-counter state bug disappeared.
> 
> 

...

> # first bad commit: [524e00b36e8c547f5582eef3fb645a8d9fc5e3df] mm:
> remove rb tree.
> 
> 
> If there is more information needed or other bisection to be done,
> please let me know.


Lukas,

Thanks for the report.  I am trying to reproduce this issue and have not
been able to trigger a memory leak.  So far I have built using the
defconfig from arch/x86/configs/x86_64_defconfig and run the C code from
the end of your report above.  It also produces some output that is not
captured in your report.  Are you sure it's the defconfig being used?

------
# ./repro
write to /proc/sys/kernel/hung_task_check_interval_secs failed: No such
file or directory
write to /proc/sys/net/core/bpf_jit_kallsyms failed: No such file or
directory
write to /proc/sys/net/core/bpf_jit_harden failed: No such file or
directory
write to /proc/sys/kernel/softlockup_all_cpu_backtrace failed: No such
file or directory
------

Note your output does not mention softlockup or hung_task issues.  This
is on 6.0.0-rc3-00207-g524e00b36e8c.  It is also worth noting that the
resulting kernel does not have /sys/kernel/debug/kmemleak.

I have also tested your reproducer with my own config which does have
the kmemleak debug file, but it did not trigger a memory leak either.  I
suspect I am missing a config option?  Are you using gcc or clang?

Thanks,
Liam

Re: Observed recent memory leak in __anon_vma_prepare

[Lukas Bulwahn]

On Tue, Oct 11, 2022 at 5:51 PM Liam Howlett <liam.howlett@oracle.com> wrote:
>
> * Lukas Bulwahn <lukas.bulwahn@gmail.com> [221011 12:35]:
> > Dear Liam, dear Matthew, dear all,
> >
> > The reproducer for the 'memory leak in __anon_vma_prepare' bug (see
> > https://elisa-builder-00.iol.unh.edu/syzkaller-next/report?id=3113810b9abd3dfeb581759df93d3171d1a90f18)
> > is reproducible, it is triggering the memory leak on the current
> > mainline (commit 60bb8154d1d7), and it was not triggering on v6.0. My
> > build config is a x86_64 defconfig.
> >
> > My git bisection showed that:
> >
> > 524e00b36e8c547f5582eef3fb645a8d9fc5e3df is the first bad commit
> > commit 524e00b36e8c547f5582eef3fb645a8d9fc5e3df
> > Author: Liam R. Howlett <Liam.Howlett@Oracle.com>
> > Date:   Tue Sep 6 19:48:48 2022 +0000
> >
> > The git bisect log is below, note that the commits 7fdbd37da5c6,
> > d0cf3dd47f0d and 0c563f148043 are marked good in the git bisect as
> > they caused bugs "BUG: Bad rss-counter state mm: ... type:MM_ANONPAGES
> > val:2". This bug report might have overshadowed the actual issue, and
> > hence the bug might have been introduced earlier, but was only visible
> > once the Bad rss-counter state bug disappeared.
> >
> >
>
> ...
>
> > # first bad commit: [524e00b36e8c547f5582eef3fb645a8d9fc5e3df] mm:
> > remove rb tree.
> >
> >
> > If there is more information needed or other bisection to be done,
> > please let me know.
>
>
> Lukas,
>
> Thanks for the report.  I am trying to reproduce this issue and have not
> been able to trigger a memory leak.  So far I have built using the
> defconfig from arch/x86/configs/x86_64_defconfig and run the C code from
> the end of your report above.  It also produces some output that is not
> captured in your report.  Are you sure it's the defconfig being used?
>
> ------
> # ./repro
> write to /proc/sys/kernel/hung_task_check_interval_secs failed: No such
> file or directory
> write to /proc/sys/net/core/bpf_jit_kallsyms failed: No such file or
> directory
> write to /proc/sys/net/core/bpf_jit_harden failed: No such file or
> directory
> write to /proc/sys/kernel/softlockup_all_cpu_backtrace failed: No such
> file or directory
> ------
>
> Note your output does not mention softlockup or hung_task issues.  This
> is on 6.0.0-rc3-00207-g524e00b36e8c.  It is also worth noting that the
> resulting kernel does not have /sys/kernel/debug/kmemleak.
>
> I have also tested your reproducer with my own config which does have
> the kmemleak debug file, but it did not trigger a memory leak either.  I
> suspect I am missing a config option?  Are you using gcc or clang?
>

Liam,

This is how I am building the kernel:

make O=$BUILD defconfig && make O=$BUILD kvm_guest.config && \
./scripts/kconfig/merge_config.sh -O $BUILD -r $BUILD/.config
kernel/configs/syzkaller-recommended.config && \
make O=$BUILD -j`nproc`

My syzkaller-recommended.config is:

CONFIG_KCOV=y
CONFIG_KCOV_INSTRUMENT_ALL=y
CONFIG_KCOV_ENABLE_COMPARISONS=y
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_CONFIGFS_FS=y
CONFIG_SECURITYFS=y
# CONFIG_RANDOMIZE_BASE is not set
CONFIG_KASAN=y
CONFIG_KASAN_INLINE=y
CONFIG_FAULT_INJECTION=y
CONFIG_FAULT_INJECTION_DEBUG_FS=y
CONFIG_FAULT_INJECTION_USERCOPY=y
CONFIG_FAILSLAB=y
CONFIG_FAIL_PAGE_ALLOC=y
CONFIG_FAIL_MAKE_REQUEST=y
CONFIG_FAIL_IO_TIMEOUT=y
CONFIG_FAIL_FUTEX=y
CONFIG_LOCKDEP=y
CONFIG_PROVE_LOCKING=y
CONFIG_DEBUG_ATOMIC_SLEEP=y
CONFIG_PROVE_RCU=y
CONFIG_DEBUG_VM=y
CONFIG_FORTIFY_SOURCE=y
CONFIG_HARDENED_USERCOPY=y
CONFIG_LOCKUP_DETECTOR=y
CONFIG_SOFTLOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y
CONFIG_DETECT_HUNG_TASK=y
CONFIG_WQ_WATCHDOG=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=140
CONFIG_RCU_CPU_STALL_TIMEOUT=100


So, it is "defconfig" + syzkaller debug features; sorry for being a
bit too brief in my first report.

The gcc version is:
gcc (Debian 8.3.0-6) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


But I doubt that the gcc version is really relevant.

I am running this in a pretty simple qemu instance. I can provide more
information on my qemu setup if needed.

Lukas

Re: Observed recent memory leak in __anon_vma_prepare

[Liam Howlett]

* Lukas Bulwahn <lukas.bulwahn@gmail.com> [221011 18:11]:
> On Tue, Oct 11, 2022 at 5:51 PM Liam Howlett <liam.howlett@oracle.com> wrote:
> >
> > * Lukas Bulwahn <lukas.bulwahn@gmail.com> [221011 12:35]:
> > > Dear Liam, dear Matthew, dear all,
> > >
> > > The reproducer for the 'memory leak in __anon_vma_prepare' bug (see
> > > https://elisa-builder-00.iol.unh.edu/syzkaller-next/report?id=3113810b9abd3dfeb581759df93d3171d1a90f18)
> > > is reproducible, it is triggering the memory leak on the current
> > > mainline (commit 60bb8154d1d7), and it was not triggering on v6.0. My
> > > build config is a x86_64 defconfig.
> > >
> > > My git bisection showed that:
> > >
> > > 524e00b36e8c547f5582eef3fb645a8d9fc5e3df is the first bad commit
> > > commit 524e00b36e8c547f5582eef3fb645a8d9fc5e3df
> > > Author: Liam R. Howlett <Liam.Howlett@Oracle.com>
> > > Date:   Tue Sep 6 19:48:48 2022 +0000
> > >
> > > The git bisect log is below, note that the commits 7fdbd37da5c6,
> > > d0cf3dd47f0d and 0c563f148043 are marked good in the git bisect as
> > > they caused bugs "BUG: Bad rss-counter state mm: ... type:MM_ANONPAGES
> > > val:2". This bug report might have overshadowed the actual issue, and
> > > hence the bug might have been introduced earlier, but was only visible
> > > once the Bad rss-counter state bug disappeared.
> > >
> > >
> >
> > ...
> >
> > > # first bad commit: [524e00b36e8c547f5582eef3fb645a8d9fc5e3df] mm:
> > > remove rb tree.
> > >
> > >
> > > If there is more information needed or other bisection to be done,
> > > please let me know.
> >
> >
> > Lukas,
> >
> > Thanks for the report.  I am trying to reproduce this issue and have not
> > been able to trigger a memory leak.  So far I have built using the
> > defconfig from arch/x86/configs/x86_64_defconfig and run the C code from
> > the end of your report above.  It also produces some output that is not
> > captured in your report.  Are you sure it's the defconfig being used?
> >
> > ------
> > # ./repro
> > write to /proc/sys/kernel/hung_task_check_interval_secs failed: No such
> > file or directory
> > write to /proc/sys/net/core/bpf_jit_kallsyms failed: No such file or
> > directory
> > write to /proc/sys/net/core/bpf_jit_harden failed: No such file or
> > directory
> > write to /proc/sys/kernel/softlockup_all_cpu_backtrace failed: No such
> > file or directory
> > ------
> >
> > Note your output does not mention softlockup or hung_task issues.  This
> > is on 6.0.0-rc3-00207-g524e00b36e8c.  It is also worth noting that the
> > resulting kernel does not have /sys/kernel/debug/kmemleak.
> >
> > I have also tested your reproducer with my own config which does have
> > the kmemleak debug file, but it did not trigger a memory leak either.  I
> > suspect I am missing a config option?  Are you using gcc or clang?
> >
> 
> Liam,
> 
> This is how I am building the kernel:
> 
> make O=$BUILD defconfig && make O=$BUILD kvm_guest.config && \
> ./scripts/kconfig/merge_config.sh -O $BUILD -r $BUILD/.config
> kernel/configs/syzkaller-recommended.config && \
> make O=$BUILD -j`nproc`
> 
> My syzkaller-recommended.config is:
> 
> CONFIG_KCOV=y
> CONFIG_KCOV_INSTRUMENT_ALL=y
> CONFIG_KCOV_ENABLE_COMPARISONS=y
> CONFIG_DEBUG_FS=y
> CONFIG_DEBUG_KMEMLEAK=y
> CONFIG_DEBUG_INFO=y
> CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
> CONFIG_KALLSYMS=y
> CONFIG_KALLSYMS_ALL=y
> CONFIG_CONFIGFS_FS=y
> CONFIG_SECURITYFS=y
> # CONFIG_RANDOMIZE_BASE is not set
> CONFIG_KASAN=y
> CONFIG_KASAN_INLINE=y
> CONFIG_FAULT_INJECTION=y
> CONFIG_FAULT_INJECTION_DEBUG_FS=y
> CONFIG_FAULT_INJECTION_USERCOPY=y
> CONFIG_FAILSLAB=y
> CONFIG_FAIL_PAGE_ALLOC=y
> CONFIG_FAIL_MAKE_REQUEST=y
> CONFIG_FAIL_IO_TIMEOUT=y
> CONFIG_FAIL_FUTEX=y
> CONFIG_LOCKDEP=y
> CONFIG_PROVE_LOCKING=y
> CONFIG_DEBUG_ATOMIC_SLEEP=y
> CONFIG_PROVE_RCU=y
> CONFIG_DEBUG_VM=y
> CONFIG_FORTIFY_SOURCE=y
> CONFIG_HARDENED_USERCOPY=y
> CONFIG_LOCKUP_DETECTOR=y
> CONFIG_SOFTLOCKUP_DETECTOR=y
> CONFIG_HARDLOCKUP_DETECTOR=y
> CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y
> CONFIG_DETECT_HUNG_TASK=y
> CONFIG_WQ_WATCHDOG=y
> CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=140
> CONFIG_RCU_CPU_STALL_TIMEOUT=100
> 
> 
> So, it is "defconfig" + syzkaller debug features; sorry for being a
> bit too brief in my first report.
> 
> The gcc version is:
> gcc (Debian 8.3.0-6) 8.3.0
> Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> But I doubt that the gcc version is really relevant.

Agreed.  I had a bug where gcc vs clang made a difference with out of
bound writing iirc, so I just wanted to make sure I was testing with the
same compiler.

> 
> I am running this in a pretty simple qemu instance. I can provide more
> information on my qemu setup if needed.
> 
> Lukas

I was able to reproduce it with this configuration, thanks.

Cheers,
Liam