linux-kernel - Re: kernel panic: audit: backlog limit exceeded

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhT51-xezOmy1SM4eP_jFH9A8Tc05wY=cwDg7oC=FgYbYQ@mail.gmail.com>
Date:   Fri, 28 Feb 2020 08:08:54 -0500
From:   Paul Moore <paul@...l-moore.com>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:     Dmitry Vyukov <dvyukov@...gle.com>,
        syzbot <syzbot+9a5e789e4725b9ef1316@...kaller.appspotmail.com>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        syzkaller <syzkaller@...glegroups.com>
Subject: Re: kernel panic: audit: backlog limit exceeded

On Fri, Feb 28, 2020 at 5:03 AM Tetsuo Handa
<penguin-kernel@...ove.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.

-- 
paul moore
www.paul-moore.com