Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 31 Aug 2020 16:25:35 -0700
From:   Kees Cook <keescook@chromium.org>
To:     Tycho Andersen <tycho@tycho.ws>,
        Christian Brauner <christian@brauner.io>
Cc:     linux-kernel@vger.kernel.org, luto@amacapital.net,
        syzbot <syzbot+3ad9614a12f80994c32e@syzkaller.appspotmail.com>,
        syzkaller-bugs@googlegroups.com, wad@chromium.org
Subject: Re: memory leak in do_seccomp
Message-ID: <202008311620.AC4A7047D@keescook>
References: <000000000000e5ea9e05ac9d16c1@google.com>
 <000000000000df80ae05ae244c2b@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000000000000df80ae05ae244c2b@google.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sun, Aug 30, 2020 at 08:50:15PM -0700, syzbot wrote:
> syzbot has found a reproducer for the following issue on:
> 
> HEAD commit:    dcc5c6f0 Merge tag 'x86-urgent-2020-08-30' of git://git.ke..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10b297d5900000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=903b9fecc3c6d231
> dashboard link: https://syzkaller.appspot.com/bug?extid=3ad9614a12f80994c32e
> compiler:       gcc (GCC) 10.1.0-syz 20200507
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=14649561900000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=118aacc1900000
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+3ad9614a12f80994c32e@syzkaller.appspotmail.com
> 
> executing program
> executing program
> executing program
> executing program
> executing program
> BUG: memory leak
> unreferenced object 0xffff88811ba93600 (size 64):
>   comm "syz-executor680", pid 6503, jiffies 4294951104 (age 21.940s)
>   hex dump (first 32 bytes):
>     00 00 00 00 00 00 00 00 08 36 a9 1b 81 88 ff ff  .........6......
>     08 36 a9 1b 81 88 ff ff 11 ce 98 89 3a d5 b4 8f  .6..........:...
>   backtrace:
>     [<00000000896418b0>] kmalloc include/linux/slab.h:554 [inline]
>     [<00000000896418b0>] kzalloc include/linux/slab.h:666 [inline]
>     [<00000000896418b0>] init_listener kernel/seccomp.c:1473 [inline]
>     [<00000000896418b0>] seccomp_set_mode_filter kernel/seccomp.c:1546 [inline]
>     [<00000000896418b0>] do_seccomp+0x8ce/0xd40 kernel/seccomp.c:1649
>     [<000000002b04976c>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
>     [<00000000322b4126>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

I haven't narrowed this down yet (and it *might* be a false positive),
but it looks like this is filter->notif. The only way that's possible is
if seccomp_notify_release() was never called *and* seccomp_filter_free()
got called... which would imply a reference counting problem. The way
there doesn't jump out at me yet, but I haven't yet decoded the C
reproducer into the actual seccomp arguments, etc.

-- 
Kees Cook