lkml.org 
[lkml]   [2020]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: kernel panic: audit: backlog limit exceeded
On Fri, Feb 28, 2020 at 1:14 AM Paul Moore <paul@paul-moore.com> wrote:
>
> On Thu, Feb 27, 2020 at 10:40 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > On Mon, Feb 24, 2020 at 11:47 PM Paul Moore <paul@paul-moore.com> wrote:
> > > On Mon, Feb 24, 2020 at 5:43 PM Eric Paris <eparis@redhat.com> wrote:
> > > > https://syzkaller.appspot.com/x/repro.syz?x=151b1109e00000 (the
> > > > reproducer listed) looks like it is literally fuzzing the AUDIT_SET.
> > > > Which seems like this is working as designed if it is setting the
> > > > failure mode to 2.
> > >
> > > So it is, good catch :) I saw the panic and instinctively chalked
> > > that up to a mistaken config, not expecting that it was what was being
> > > tested.
> >
> > Yes, this audit failure mode is quite unpleasant for fuzzing. And
> > since this is not a top-level syscall argument value, it's effectively
> > impossible to filter out in the fuzzer. Maybe another use case for the
> > "fuzer lockdown" feature +Tetsuo proposed.
> > With the current state of the things, I think we only have an option
> > to disable fuzzing of audit. Which is pity because it has found 5 or
> > so real bugs in audit too.
> > But this happened anyway because audit is only reachable from init pid
> > namespace and syzkaller always unshares pid namespace for sandboxing
> > reasons, that was removed accidentally and that's how it managed to
> > find the bugs. But the unshare is restored now:
> > https://github.com/google/syzkaller/commit/5e0e1d1450d7c3497338082fc28912fdd7f93a3c
> >
> > As a side effect all other real bugs in audit will be auto-obsoleted
> > in future if not fixed because they will stop happening.
>
> On the plus side, I did submit fixes for the other real audit bugs
> that syzbot found recently and Linus pulled them into the tree today
> so at least we have that small victory.

+1!

> We could consider adding a fuzz-friendly build time config which would
> disable the panic failsafe, but it probably isn't worth it at the
> moment considering the syzbot's pid namespace limitations.
>
> --
> paul moore
> www.paul-moore.com

\
 
 \ /
  Last update: 2020-03-02 09:43    [W:0.075 / U:4.992 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site