From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
linux-kernel@vger.kernel.org,
syzbot <syzbot+8ab2d0f39fb79fe6ca40@syzkaller.appspotmail.com>,
Eric Biggers <ebiggers@kernel.org>
Subject: Re: [PATCH] /dev/mem: Bail out upon SIGKILL when reading memory.
Date: Thu, 22 Aug 2019 18:59:25 +0900 [thread overview]
Message-ID: <201908220959.x7M9xP8r011133@www262.sakura.ne.jp> (raw)
In-Reply-To: 20190820222403.GB8120@kroah.com
Tetsuo Handa wrote:
> Greg Kroah-Hartman wrote:
> > Oh, nice! This shouldn't break anything that is assuming that the read
> > will complete before a signal is delivered, right?
> >
> > I know userspace handling of "short" reads is almost always not there...
>
> Since this check will give up upon SIGKILL, userspace won't be able to see
> the return value from read(). Thus, returning 0 upon SIGKILL will be safe. ;-)
> Maybe we also want to add cond_resched()...
>
> By the way, do we want similar check on write_mem() side?
> If aborting "write to /dev/mem" upon SIGKILL (results in partial write) is
> unexpected, we might want to ignore SIGKILL for write_mem() case.
> But copying data from killed threads (especially when killed by OOM killer
> and userspace memory is reclaimed by OOM reaper before write_mem() returns)
> would be after all unexpected. Then, it might be preferable to check SIGKILL
> on write_mem() side...
>
Ha, ha. syzbot reported the same problem using write_mem().
https://syzkaller.appspot.com/text?tag=CrashLog&x=1018055a600000
We want fatal_signal_pending() check on both sides.
By the way, write_mem() worries me whether there is possibility of replacing
kernel code/data with user-defined memory data supplied from userspace.
If write_mem() were by chance replaced with code that does
while (1);
we won't be able to return from write_mem() even if we added fatal_signal_pending() check.
Ditto for replacing local variables with unexpected values...
next prev parent reply other threads:[~2019-08-22 9:59 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-20 22:06 [PATCH] /dev/mem: Bail out upon SIGKILL when reading memory Tetsuo Handa
2019-08-20 22:24 ` Greg Kroah-Hartman
2019-08-21 0:07 ` Tetsuo Handa
2019-08-22 9:59 ` Tetsuo Handa [this message]
2019-08-22 13:35 ` Greg Kroah-Hartman
2019-08-22 14:00 ` Tetsuo Handa
2019-08-22 16:42 ` Greg Kroah-Hartman
2019-08-22 17:11 ` Dmitry Vyukov
2019-08-22 21:17 ` Tetsuo Handa
2019-08-22 23:59 ` Dmitry Vyukov
2019-08-23 8:17 ` Tetsuo Handa
2019-08-23 16:47 ` Dmitry Vyukov
2019-10-08 9:57 ` Kernel config for fuzz testing Tetsuo Handa
2019-08-22 21:29 ` [PATCH] /dev/mem: Bail out upon SIGKILL when reading memory Linus Torvalds
2019-08-22 22:08 ` Linus Torvalds
2019-08-23 9:16 ` Ingo Molnar
2019-08-23 16:39 ` Linus Torvalds
2019-08-24 16:14 ` Ingo Molnar
2019-08-24 17:40 ` Linus Torvalds
2019-08-24 20:22 ` Ingo Molnar
2019-08-24 20:56 ` Linus Torvalds
2019-08-30 9:56 ` David Laight
2019-08-25 5:49 ` Tetsuo Handa
2019-08-25 9:59 ` Ingo Molnar
2019-08-25 10:35 ` Tetsuo Handa
2019-08-25 10:48 ` Ingo Molnar
2019-08-25 16:54 ` Linus Torvalds
2019-08-26 10:40 ` Tetsuo Handa
2019-08-26 11:19 ` Ingo Molnar
2019-08-26 15:02 ` Rewriting read_kmem()/write_kmem() ? Tetsuo Handa
2019-08-23 11:46 ` [PATCH] /dev/mem: Bail out upon SIGKILL when reading memory Tetsuo Handa
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=201908220959.x7M9xP8r011133@www262.sakura.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=arnd@arndb.de \
--cc=ebiggers@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzbot+8ab2d0f39fb79fe6ca40@syzkaller.appspotmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).