All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: syzbot <syzbot+85da7ac734f7ba432ee4@syzkaller.appspotmail.com>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	linux-ext4@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Subject: Re: WARNING in ext4_invalidatepage
Date: Tue, 16 Oct 2018 11:53:41 -0400	[thread overview]
Message-ID: <20181016155341.GF8983@thunk.org> (raw)
In-Reply-To: <CACT4Y+bs72L4GKF7K6zHHqDGfURymzUke7UT6CKtakLWu+f94g@mail.gmail.com>

On Tue, Oct 16, 2018 at 04:02:07PM +0200, Dmitry Vyukov wrote:
> I am not sure how exactly this should be classified. To significant
> degree these "$FOO" discriminations are informational and only really
> affect the data format passed in.

The problem is that putting something which is simply and plainly
*wrong* is going to be actively misleading.  You *have* to know what
ioctl you are trying to be trying to execute because some of them
require input data structures that you have to fill in, or that it
requires a file descriptor as opposed to an integer or a pointer to a
struct.  I assume you're not just picking ioctl numbers purely at
random, right?

So I assume you had a table that said, this ioctl, 0x6611 takes a file
descriptor, and has thus-and-so-a-name.  If that name is wrong, I'd
say it's pretty clearly a bug, right?

(I'll again gently point out that a tiny amount of work in making
syzkaller a tiny bit more developer toil would make it much more
effective, since all of this extra developer toil --- now I know I
can't even trust the $FOO discriminators to be right --- makes
syzkaller less scalable by pursuading developers that it's not
worthwhile to pay attention...)

> > The patch I referenced in my previous e-mail protects against
> > additional scenarios where someone might be trying to punch a whole
> > into a file that is being swapped into the bootloader ioctl.  This
> > particular ioctl isn't yet being used by anyone, so it had some other
> > issues as well, such as not interacting well with inline_data-enabled
> > file systems --- not that any bootloader would be small enough that it
> > would fit in an inline_data inode, but we're basically proofing the
> > code against a malicious (or buggy) root-privileged program... such as
> > syzbot.  :-)
> 
> ... or paving the way to opening all of this to non-root users. Why
> not if not bugs? ;)

The intent behind this particular ioctl is used to install a boot
loader.  It will *never* be opened to non-root users.  It doesn't even
make sense to make it available to pseudo-containers-root users.  :-)

							- Ted

  reply	other threads:[~2018-10-16 15:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-08 16:18 WARNING in ext4_invalidatepage syzbot
2018-10-08 16:29 ` Dmitry Vyukov
2018-10-09  1:34   ` Theodore Y. Ts'o
2018-10-15 13:22     ` Dmitry Vyukov
2018-10-15 18:08       ` Theodore Y. Ts'o
2018-10-16 14:02         ` Dmitry Vyukov
2018-10-16 15:53           ` Theodore Y. Ts'o [this message]
2018-10-30 12:09             ` Dmitry Vyukov
2018-10-30 12:16             ` 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=20181016155341.GF8983@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=dvyukov@google.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzbot+85da7ac734f7ba432ee4@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.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.