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: <8b130791-d48a-6505-f3f1-d08cada23d8d@i-love.sakura.ne.jp>
Date:   Sat, 14 Dec 2019 17:39:02 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Greg KH <gregkh@...uxfoundation.org>
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 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)".

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

>>> 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.

"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.

> 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.