linux-kernel - Re: BUG: unable to handle kernel NULL pointer dereference in mem_serial

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20191214090905.GA3322570@kroah.com>
Date:   Sat, 14 Dec 2019 10:09:05 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:     Dmitry Vyukov <dvyukov@...gle.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        syzbot <syzbot+f4f1e871965064ae689e@...kaller.appspotmail.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        asierra@...-inc.com, ext-kimmo.rautkoski@...sala.com,
        Jiri Slaby <jslaby@...e.com>,
        kai heng feng <kai.heng.feng@...onical.com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-serial <linux-serial@...r.kernel.org>,
        mika.westerberg@...ux.intel.com, o.barta89@...il.com,
        paulburton@...nel.org, sr@...x.de,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        yegorslists@...glemail.com
Subject: Re: BUG: unable to handle kernel NULL pointer dereference in
 mem_serial_out

On Sat, Dec 14, 2019 at 05:39:02PM +0900, Tetsuo Handa wrote:
> On 2019/12/14 16:55, Greg KH wrote:
> >>>> That suggestion got no response for two months.
> >>>>
> >>>>   https://lkml.kernel.org/r/3e4e2b6b-7828-54ab-cf28-db1a396d7e20@i-love.sakura.ne.jp
> >>>>
> >>>> Unless we add such kernel config option to upstream kernels, it will become
> >>>> a whack-a-mole game.
> >>>
> >>> It will be a whack-a-mole game no matter what.
> >>>
> >>> Yes, /dev/mem/ makes no sense to fuzz.  Neither does other things (like
> >>> serial port memory addresses.)
> >>
> >> /dev/mem makes sense to fuzz. Ditto for other things.
> > 
> > What?  What are you going to find if you randomly start to write to
> > /dev/mem?  How are we supposed to "fix" that?
> > 
> 
> When did I say "writing to random addresses" ? If you saw my suggestion, you
> will find that "fuzzer will be able to test reading from random addresses,
> writing to safe addresses (in order to find new lock dependency which would
> otherwise be unnoticed)".

I don't remember the suggestion specifically, sorry.  But how would you
figure out what those "safe addresses" really are?  They will change on
every single platform.

And why would this even help anything?  What lock dependency?

> Disabling everything using kernel config option is overkill. What you are saying
> is "never try to fuzz USB drivers" by excluding USB drivers from fuzz targets.

I never said that.

> There is no need to disable whole tests. We need to exclude only stupid operations
> (e.g. forever repeating SysRq-t) from fuzz targets.

Ok, like I said, configuring serial ports as root is a stupid operation
to think it is totally safe :)

> >>> You just will have a list of things that you "do not fuzz as these are
> >>> dangerous".  Nothing new here, any os will have that.
> >>
> >> The list of kernel config options will become too complicated to maintain.
> >> If we can have one kernel config option, we can avoid maintaining
> >> the list of kernel config options (which keeps changing over time).
> > 
> > Use the newly added security_locked_down() call, that gives you a great
> > indication that root can cause problems for those things.
> > 
> 
> No. security_locked_down() is not for fuzz kernels but for real kernels.

Yes, but it gives you a huge hint that this is something that you could
do as root that is "bad" and can harm the system.

> "enum lockdown_reason" is overkill, it just keeps fuzzers away from finding bugs.
> For example, if ftrace code has bugs but ftrace_event_open() prevents from
> fuzzing due to security_locked_down(LOCKDOWN_TRACEFS) ? Fuzz kernels should not
> count on security_locked_down() returning errors. That is no different from
> disabling everything using kernel config options.

They all might not be correct, but again they provide a hint.

> > And it's not a config thing, it's a functionality thing within features,
> > as is explicitly shown by this very thread for the serial port memory
> > location.
> 
> My suggestion is not for real kernels but for fuzz kernels.

So fuzz kernels are not real?  :)