Re: memory leak in do_seccomp
From: Sudip Mukherjee
Date: Sun Aug 01 2021 - 17:12:03 EST
On Sun, Aug 1, 2021 at 4:26 AM Kees Cook <keescook@xxxxxxxxxxxx> wrote:
> On Sat, Jul 31, 2021 at 08:20:29PM +0100, Sudip Mukherjee wrote:
> > Hi All,
> > We had been running syzkaller on v5.10.y and a "memory leak in
> > do_seccomp" was being reported on it. I got some time to check that
> > today and have managed to get a syzkaller
> > reproducer. I dont have a C reproducer which I can share but I can use
> > the syz-reproducer to reproduce this with next-20210730.
> > The old report on v5.10.y is at
> > https://elisa-builder-00.iol.unh.edu/syzkaller/report?id=f6ddd3b592f00e95f9cbd2e74f70a5b04b015c6f
> Thanks for the details!
> Is this the same as what syzbot saw here (with a C reproducer)?
Looks similar but it says its fixed and I still get it with the
reproducer I have.
> I can't figure out what happened with the "Patch testing request" that
> was made; there's no link?
Looks like it has been merged with a566a9012acd ("seccomp: don't leak
memory when filter install races")
> > BUG: memory leak
> > unreferenced object 0xffff888019282c00 (size 512):
> > comm "syz-executor.1", pid 7389, jiffies 4294761829 (age 17.841s)
> > hex dump (first 32 bytes):
> > 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> > backtrace:
> > [<00000000762c0963>] do_seccomp+0x2d5/0x27d0
> Can you run "./scripts/faddr2line do_seccomp+0x2d5/0x27d0" for this? I
> expect it'll be:
> sfilter = kzalloc(sizeof(*sfilter), GFP_KERNEL | __GFP_NOWARN);
Yes, it is from "(inlined by) seccomp_prepare_filter at kernel/seccomp.c:661".
$ scripts/faddr2line vmlinux do_seccomp+0x2d5/0x27d0
kmalloc at include/linux/slab.h:591
(inlined by) kzalloc at include/linux/slab.h:721
(inlined by) seccomp_prepare_filter at kernel/seccomp.c:661
(inlined by) seccomp_prepare_user_filter at kernel/seccomp.c:703
(inlined by) seccomp_set_mode_filter at kernel/seccomp.c:1852
(inlined by) do_seccomp at kernel/seccomp.c:1972
> > [<0000000006e512d1>] do_syscall_64+0x3b/0x90
> > [<0000000094ae9ff8>] entry_SYSCALL_64_after_hwframe+0x44/0xae
> My best guess is there is some LISTENER refcount state we can get into
> where all the processes die, but a reference is left alive.
Will be happy to run any debug patch if you need.