Hi Kees, 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)? > https://syzkaller.appspot.com/bug?id=2809bb0ac77ad9aa3f4afe42d6a610aba594a987 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". I did: $ scripts/faddr2line vmlinux do_seccomp+0x2d5/0x27d0 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 > <snip> > > 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. -- Regards Sudip
