Re: kernel panic: audit: backlog limit exceeded

From: Dmitry Vyukov <dvyukov@google.com>
To: Paul Moore <paul@paul-moore.com>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	syzbot <syzbot+9a5e789e4725b9ef1316@syzkaller.appspotmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	syzkaller <syzkaller@googlegroups.com>
Subject: Re: kernel panic: audit: backlog limit exceeded
Date: Mon, 2 Mar 2020 09:47:21 +0100	[thread overview]
Message-ID: <CACT4Y+YgoyBCoPYxXOb8oQjXYc+Q-cZLPi6y1Yrx_mnfzOQafQ@mail.gmail.com> (raw)
In-Reply-To: <CAHC9VhT51-xezOmy1SM4eP_jFH9A8Tc05wY=cwDg7oC=FgYbYQ@mail.gmail.com>

On Fri, Feb 28, 2020 at 2:09 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Fri, Feb 28, 2020 at 5:03 AM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
> > On 2020/02/28 9:14, Paul Moore wrote:
> > > 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.
> >
> > I think adding a fuzz-friendly build time config does worth. For example,
> > we have locations where printk() emits "BUG:" or "WARNING:" and fuzzer
> > misunderstands that a crash occurred. PID namespace is irrelevant.
> > I proposed one at
> > https://lkml.kernel.org/r/20191216095955.9886-1-penguin-kernel@I-love.SAKURA.ne.jp .
> > I appreciate your response.
>
> To be clear, I was talking specifically about the intentional panic in
> audit_panic().  It is different from every other panic I've ever seen
> (perhaps there are others?) in that it doesn't indicate a serious
> error condition in the kernel, it indicates that audit records were
> dropped.  It seems extreme to most people, but some use cases require
> that the system panic rather than lose audit records.
>
> My suggestion was that we could introduce a Kconfig build flag that
> syzbot (and other fuzzers) could use to make the AUDIT_FAIL_PANIC case
> in audit_panic() less panicky.  However, as syzbot isn't currently
> able to test the kernel's audit code due to it's pid namespace
> restrictions, it doesn't make much sense to add this capability.  If
> syzbot removes that restriction, or when we get to the point that we
> support multiple audit daemons, we can revisit this.

Yes, we need some story for both panic and pid ns.

We also use a separate net ns, but allow fuzzer to create some sockets
in the init net ns to overcome similar limitations. This is done using
a pseudo-syscall hack:
https://github.com/google/syzkaller/blob/4a4e0509de520c7139ca2b5606712cbadc550db2/executor/common_linux.h#L1546-L1562

But the pid ns is different and looks a bit harder as we need it
during send of netlink messages.

As a strawman proposal: the comment there says "for now":

/* Only support auditd and auditctl in initial pid namespace
 * for now. */
if (task_active_pid_ns(current) != &init_pid_ns)
  return -EPERM;

What does that mean? Is it a kind of TODO? I mean if removing that
limitation is useful for other reasons, then maybe we could kill 2
birds with 1 stone.