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

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] [day] [month] [year] [list]

Message-ID: <Y7TDZRpDVysLdq+N@mit.edu>
Date:   Tue, 3 Jan 2023 19:08:05 -0500
From:   "Theodore Ts'o" <tytso@....edu>
To:     Aleksandr Nogikh <nogikh@...gle.com>
Cc:     syzbot <syzbot+3c45794f522ad93b0eb6@...kaller.appspotmail.com>,
        adilger.kernel@...ger.ca, linux-ext4@...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 (2)

On Tue, Jan 03, 2023 at 12:22:53PM +0100, Aleksandr Nogikh wrote:
> Hi Ted,
> 
> Syzkaller already tries to avoid such situations, but in this
> particular case, it has corrupted the mount options[1] and did not
> recognize the problem. Though, as I understand, this string was
> nevertheless valid to the kernel. Otherwise it would have aborted the
> mount early (?).
> 
> [1] grpjquota=Jnoinit_itable(errors=remount-ro,minixdf,jqfmt=vfsv0,usrjquota=."

Yes, it's considered valid with the name of the journaled group quota
file being "Jnoinit_itable(errors=remount-ro".  Which is very odd, but
in theory, if that file existed, quotaon would have tried to find that
file and used it as the group quota.

(Old-style quota files, which we still support because (a) there might
be RHEL users using system setups that haven't been updated since the
RHEL3/RHEL4 days and (b) there are still stackoverflow answers and
other FAQ posts on the web telling people how to enable quota using
these ancient schemes, are passed into kernel, but aren't actually
used by the kernel; instead the userspace quota tools parse either
/etc/mtab or /proc/mounts to find the relevant mount option and then
try to use the named file as the user or group quota file.)

> I've sent a PR that should make the syzkaller logic more robust to
> such broken options strings:
> https://github.com/google/syzkaller/pull/3604

Thanks for fixing this so promptly!

						- Ted