netdev - Re: net/core: BUG in copy_net

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CACT4Y+aw0e-NLuBqM=WQsdik1VsNKB3J4acdDH6zC3wu0wUoKw@mail.gmail.com>
Date:   Tue, 15 Jan 2019 11:36:07 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     zzoru <zzoru007@...il.com>, Kirill Tkhai <ktkhai@...tuozzo.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Andrey Vagin <avagin@...tuozzo.com>,
        "dsahern@...il.com" <dsahern@...il.com>,
        "nicolas.dichtel@...nd.com" <nicolas.dichtel@...nd.com>,
        "tyhicks@...onical.com" <tyhicks@...onical.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "syzkaller@...glegroups.com" <syzkaller@...glegroups.com>
Subject: Re: net/core: BUG in copy_net_ns()

On Mon, Jan 14, 2019 at 7:30 PM Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
> zzoru <zzoru007@...il.com> writes:
>
> > I think that it is exactly same to:
> > https://groups.google.com/forum/#!searchin/linux.kernel/cleanup_net$20is$20slow%7Csort:date/linux.kernel/IMJ9OzonDSI/QH86oy1PAQAJ
> > Already, patch was maded, but maybe he forgot to push it.
>
> That patch was made to address speed, and lifetime of network stack
> objects.  At best it will make things go faster (a good thing), and
> reduce the memory consumption during a test (another good thing).
> The patch you point to will not correct your memory corruption.
>
> So right now the best hypothesis seems to be Dmitriy's idea that
> there is stack overflow causing corruption. You have a lot of stack
> debugging already enabled but I don't see CONFIG_VMAP_STACK enabled
> which might catch something ordinary stack overflow checking won't.
>
> Any chance you can enable CONFIG_VMAP_STACK and see if it is stack
> overflow?
>
> With a little luck you will catch the stack overflow in the act and we
> can see the problematic code path.

Most likely the stack overflow should be detectable with
CONFIG_VMAP_STACK. But CONFIG_VMAP_STACK is incompatible with KASAN:
https://bugzilla.kernel.org/show_bug.cgi?id=202009

I reproduced the other stack overflow without KASAN and without
CONFIG_VMAP_STACK and it was detected as "corrupted stack end
detected inside scheduler". We can try the same here. But without
KASAN and with CONFIG_VMAP_STACK should be more reliable.

But how I read it is if we see wb_workfn in stacks, kernel memory is
corrupted. Overflow at that async stack is not dependent on how
exactly low memory condition was provoked.