linux-ext4 - Re: [syzbot] [ext4?] kernel panic: EXT4-fs (device loop0): panic forced after error (3)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 17 Aug 2023 22:10:38 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     sandeen@...hat.com,
        syzbot <syzbot+27eece6916b914a49ce7@...kaller.appspotmail.com>,
        adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        llvm@...ts.linux.dev, nathan@...nel.org, ndesaulniers@...gle.com,
        syzkaller-bugs@...glegroups.com, trix@...hat.com
Subject: Re: [syzbot] [ext4?] kernel panic: EXT4-fs (device loop0): panic
 forced after error (3)

On Thu, Aug 17, 2023 at 09:47:39AM -0700, Eric Biggers wrote:
> 
> Eric S. is correct that for a filesystem image to enable panic on error, support
> for panic on error should have to be properly consented to by the kernel
> configuration, for example through an fs.allow_panic_on_error sysctl.

I disagree.  It's up to the system administrator, not the kernel ---
and the system adminsitrator is perfectly free to run e2fsck on a
random file system, or to use tune2fs to adjust the panic on error
setting on the file system, befure using their root powers to mount
the file system.

Root can do many things that cause the system to reboot.  For example,
the system adminsirtator could run /sbin/reboot.  Should the kernel
"consent" by setting fs.allow_reboot_system_call_to_work before the
root user can run the /sbin/reboot binary?  Hopefully it's obvious why
this makes absolutely no sense.

> It can be argued that this not important, or not worth implementing when the
> default will need to remain 1 for backwards compatibility.  Or even that
> syzkaller should work around it in the mean time.  But it is incorrect to write
> "This is fundamentally a syzbot bug."

Well, the current behaviour is Working as Intended.  And if syzbot is
going about whining about things that are Working as Intended, it's
not fit for the upostream developers' purpose.

As another example, root can set a real-time priority of a process to
be at a level where it will prempt all other processes, including
kernel threads.  Do enough of these, and you *will* lock up the
kernel.  Again, should there be a sysctl that allows real-time
priorities to work?  Or do we teach syzbot that doing things that are
documented to cause the kernel to lock up are not something that's
worthy of a report.  In the past, syzbot issued a *huge* amount of
noise caused by precisely to this.  Upstream developers complained
that it was a false positive, and syzbot was adjusted to Stop Doing
That.

						- Ted