linux-kernel - Re: Observed recent memory leak in __anon_vma

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 11 Oct 2022 18:11:00 +0200
From:   Lukas Bulwahn <lukas.bulwahn@...il.com>
To:     Liam Howlett <liam.howlett@...cle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Linux-MM <linux-mm@...ck.org>,
        kernel-janitors <kernel-janitors@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "maple-tree@...ts.infradead.org" <maple-tree@...ts.infradead.org>,
        Matthew Wilcox <willy@...radead.org>
Subject: Re: Observed recent memory leak in __anon_vma_prepare

On Tue, Oct 11, 2022 at 5:51 PM Liam Howlett <liam.howlett@...cle.com> wrote:
>
> * Lukas Bulwahn <lukas.bulwahn@...il.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@...cle.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