All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Dmitry Vyukov <dvyukov@google.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	syzbot <syzbot+f4f1e871965064ae689e@syzkaller.appspotmail.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	asierra@xes-inc.com, ext-kimmo.rautkoski@vaisala.com,
	Jiri Slaby <jslaby@suse.com>,
	kai heng feng <kai.heng.feng@canonical.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-serial <linux-serial@vger.kernel.org>,
	mika.westerberg@linux.intel.com, o.barta89@gmail.com,
	paulburton@kernel.org, sr@denx.de,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	yegorslists@googlemail.com
Subject: Re: BUG: unable to handle kernel NULL pointer dereference in mem_serial_out
Date: Sat, 14 Dec 2019 12:25:50 +0100	[thread overview]
Message-ID: <20191214112550.GA3328133@kroah.com> (raw)
In-Reply-To: <1634f244-543c-28c6-c322-c3d981c3a973@i-love.sakura.ne.jp>

On Sat, Dec 14, 2019 at 07:28:02PM +0900, Tetsuo Handa wrote:
> On 2019/12/14 18:09, Greg KH wrote:
> > 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.
> 
> ----------
> +#ifdef CONFIG_KERNEL_BUILT_FOR_FUZZ_TESTING
> +static char dummybuf[PAGE_SIZE];
> +#endif
> ----------
> 
> ----------
>                         ptr = xlate_dev_mem_ptr(p);
>                         if (!ptr) {
>                                 if (written)
>                                         break;
>                                 return -EFAULT;
>                         }
> +#ifndef CONFIG_KERNEL_BUILT_FOR_FUZZ_TESTING
>                         copied = copy_from_user(ptr, buf, sz);
> +#else
> +                       copied = copy_from_user(dummybuf, buf, min(sizeof(dummybuf), sz));
> +#endif

Ick ick ick, we don't like #ifdefs in .c files for a reason :)

>                         unxlate_dev_mem_ptr(p, ptr);
> ----------
> 
> How dummybuf cannot be "safe address" ?

Sure, that's safe, but don't try to change what I originally said about
writing to random /dev/mem addresses please.

> > And why would this even help anything?  What lock dependency?
> > 
> 
> copy_from_user() can trigger page fault which involves memory allocation.
> And direct reclaim which is performed within memory allocation operation
> is full of subtle dependency bugs. :-(

It's as if you want a memory/platform type to be a "fuzz target", right?
You aren't going to go around and try to put the above crazyness into
each and every spot in the kernel that wants to write to a
user-specified address.

Fuzzing the kernel is great, but remember it's a means to an end, that
of trying to ensure that the kernel has less bugs than before.  Forcing
the kernel to adapt a memory model that is not what it "normally" uses
kind of goes against your main goal here, right?

And have you all really run out of apis that are all now bug free that
you are going after these types of ones?

thanks,

greg k-h

  reply	other threads:[~2019-12-14 11:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-07  6:25 BUG: unable to handle kernel NULL pointer dereference in mem_serial_out syzbot
2019-12-12 10:57 ` Greg KH
2019-12-13  9:02   ` Dmitry Vyukov
2019-12-13  9:33     ` Greg KH
2019-12-13 10:00       ` Dmitry Vyukov
2019-12-13 10:10         ` Greg KH
2019-12-13 10:39           ` Dmitry Vyukov
2019-12-13 11:26             ` Greg KH
2019-12-17 10:48               ` Dmitry Vyukov
2020-01-07 17:02                 ` Dmitry Vyukov
2019-12-13 14:31         ` Tetsuo Handa
2019-12-13 16:07           ` Greg KH
2019-12-14  0:48             ` Tetsuo Handa
2019-12-14  7:55               ` Greg KH
2019-12-14  8:39                 ` Tetsuo Handa
2019-12-14  9:09                   ` Greg KH
2019-12-14 10:28                     ` Tetsuo Handa
2019-12-14 11:25                       ` Greg KH [this message]
2019-12-18  0:55         ` Tetsuo Handa
2019-12-18  6:53           ` Dmitry Vyukov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191214112550.GA3328133@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=asierra@xes-inc.com \
    --cc=dvyukov@google.com \
    --cc=ext-kimmo.rautkoski@vaisala.com \
    --cc=jslaby@suse.com \
    --cc=kai.heng.feng@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=o.barta89@gmail.com \
    --cc=paulburton@kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=sr@denx.de \
    --cc=syzbot+f4f1e871965064ae689e@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=torvalds@linux-foundation.org \
    --cc=yegorslists@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.