LKML Archive on
help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <>
To: Dmitry Vyukov <>
Cc: Tetsuo Handa <>,
	syzbot <>,
	syzkaller-bugs <>,
	syzkaller <>,
	Andreas Dilger <>,, LKML <>
Subject: Re: kernel panic: EXT4-fs (device loop0): panic forced after error
Date: Sun, 6 May 2018 09:50:02 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sun, May 06, 2018 at 11:15:45AM +0200, Dmitry Vyukov wrote:
> >> I don't get why syzbot considers this a bug.  It created a corrupted
> >> file system, mounted it as root, and said file system had the flag
> >> which says, "panic if you find a file system corruption".
> > In what world is this a security bug?
> Do you mean why syzbot considers kernel panics as something to report?
> Or why syzbot has not understood why this panic is somehow special?
> syzbot doesn't report only security problems. It just reports bugs.
> E.g. NULL derefs and deadlocks are also not security bugs, but are
> reported.

EXT4-fs (device loop0): panic forced after error

This is working as intended.  See the tune2fs man page.

     -e error-behavior
              Change the behavior of the kernel code when errors are
              detected.  In all cases, a filesystem error will cause
              e2fsck(8) to check the filesystem on the next boot.
              error-behavior can be one of the following:

                   continue    Continue normal execution.

                   remount-ro  Remount filesystem read-only.

                   panic       Cause a kernel panic.

> Can you please give me background regarding purpose of this flag?
> What's the intended use case? And what exactly is corrupted?

When the file system is corrupted, you might not want to continue
processing.  If you have some kind High Availability system available,
having the system shutdown so the secondary/backup system can take
over for the corrupted file system.  This might be better than
continuing to steer the spaceship, or continuning to control the x-ray
dosage received by a patient, etc., etc.

> If kernel detects that an image is corrupted during mount shouldn't it
> just report an error?

The problem is that this would, in the general case, putting in a full
or partial kernel-mode fsck and requiring it to be run before mount.
Sure, I could add more complexity in the system to bypass the check in
iget() if it is being called from mount, but what if SELinux is
running and it tries to fetch an xattr?  Or what if Syzkaller's
repro.c decides to start reading or writing files, or deleting files
in the directory?

More generally, root can always do stuff which will cause the system
to crash or shut down.  It can kexec a file containing garbage; it can
call the shutdown system call.  Presumably it is not reasonable to
require the kexec(2) system call to validate the image before
transfering control to it?  After all, that would require solving the
Halting Problem.  :-)

> If I am reading this correctly, any USB cable
> that plug into my computer can shut it down. Or maybe even existing
> cables can shut down all computers in a country on a remote command.
> Am I missing something here?

If you have physical access to the machine, you can shut it down.  And
there cases when shutting down a system or even all of the computers
in a cluster is the right thing to do.  Not shutting down the computer
could actually have harmful physical effects (e.g., a transformer
blowing up, a centrifuge tearing itself apart[1], etc.)  The system
administrator should have the choice to set up a file system such that
if an inconsistency is detected.

						- Ted

[1] Although if the centrifuge is in Iran, and you are in the NSA,
that might be considered a feature, not a bug.  Of course, if the
transformer is in the US or Germany, and the entity triggering a bug
which causes it to blow up is sponsored by Russia, then of course
that's a different story.  :-)

  reply	other threads:[~2018-05-06 13:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-06  0:57 syzbot
2018-05-06  2:24 ` Theodore Y. Ts'o
2018-05-06  5:03   ` Tetsuo Handa
2018-05-06  9:15     ` Dmitry Vyukov
2018-05-06 13:50       ` Theodore Y. Ts'o [this message]
2018-05-06 13:31     ` Theodore Y. Ts'o
2018-05-06 14:40       ` Tetsuo Handa
2018-05-06 20:30         ` Theodore Y. Ts'o
2018-05-14  9:12           ` Dmitry Vyukov
2018-06-12 14:01             ` 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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: kernel panic: EXT4-fs (device loop0): panic forced after error' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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