Re: memory leak in do_seccomp

[Sudip Mukherjee]

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