linux-kernel - Distinguishing kernel bugs from invalid inputs

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>] [day] [month] [year] [list]

Message-ID: <CACT4Y+Z1BsQvZG38AJwhZ5xLUY8rC-Y4BBwbDSP2uYrMA66v=A@mail.gmail.com>
Date:   Thu, 19 Oct 2017 10:24:47 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "Levin, Alexander" <alexander.levin@...izon.com>,
        Mark Rutland <mark.rutland@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Josh Triplett <josh@...htriplett.org>
Cc:     syzkaller <syzkaller@...glegroups.com>
Subject: Distinguishing kernel bugs from invalid inputs

Hello,

As you may know we are doing some automated kernel testing with
syzkaller fuzzer. For that we need to be able to distinguish kernel
bugs (something to notify kernel mailing lists about) from console
messages provoked by various invalid inputs to kernel (effectively
EINVAL coming from user-space or devices, either real or test). From
time to time we have problems with "WARNING:" messages.

Most of the time they do mean kernel bugs (just not fatal), and we
found 100+ bugs based on WARNING messages and kernel mostly follows
this meaning of WARNING. But every now and then they are used for
invalid inputs and we see some push back from developers saying that
it's fine to use WARNING for, say, bad data coming from a USB device.
Comments in include/asm-generic/bug.h are not definitive in this
regard.

So I would like kernel community to define some policy around console
output that allows automatically detecting when there is a bug in
kernel, and then document it so that we don't need to get back to this
question again and again. I think it will also be useful for
administrators and users staring at dmesg. And have obvious
implications when panic_on_warn is set (not sure if it's used by
anybody in production, though). I also heard about effective
(unintentional) local DoS caused by buggy programs provoking WARNINGs
in tight loop when serial output is actually always captured.

I don't have strong preference as to how exactly it should look like.
And to make it clear, printing messages and stacks, if necessary, on
invalid inputs if fine, it just needs to be distinguishable from
kernel bugs. We could use pr_err (not containing "WARNING"!), or there
was a mention of a new macro a-la PROBLEM(). Other options?

Thoughts?

Thanks