LKML Archive on
help / color / mirror / Atom feed
From: Tetsuo Handa <>
To: "Theodore Y. Ts'o" <>,
	syzbot <>,,
Subject: Re: kernel panic: EXT4-fs (device loop0): panic forced after error
Date: Sun, 6 May 2018 14:03:57 +0900	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 2018/05/06 11:24, Theodore Y. Ts'o wrote:
> On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
>> Hello,
>> syzbot found the following crash on:
>> EXT4-fs error (device loop0): ext4_iget:4756: inode #2: comm
>> syz-executor909: root inode unallocated
>> Kernel panic - not syncing: EXT4-fs (device loop0): panic forced after error
> 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".

"panic if file system error occurred (so that we won't continue with
inconsistent state)", doesn't it?

Since syzbot is hitting this error path inside mount() request, calling
panic() when something went wrong inside mount() request might be
overkill. We can recover without shutting down the system, can't we?

> In what world is this a security bug?  There's a *reason* why I've
> always said people who want to containers to be allowed to mount
> arbitrary file systems controlled by potentially malicious container
> users are insane....
> I could mark this as a one-off invalid bug, but if syzkaller is going
> to be generating classes of corrupted file systems like this, and are
> going to be complaing about how this causes the kernel to crash, then
> we have a fundamental syzkaller BUG.
> 					- Ted

If we won't try to recover this case, this specific report would be
marked as "#syz invalid".

  reply	other threads:[~2018-05-06  5:04 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 [this message]
2018-05-06  9:15     ` Dmitry Vyukov
2018-05-06 13:50       ` Theodore Y. Ts'o
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).