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  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]
Date:   Tue, 12 May 2020 00:55:04 +0000
Subject: [Bug 207635] EXT4-fs error (device sda3): ext4_lookup:1701: inode
 #...: comm find: casefold flag without casefold feature; EXT4-fs (sda3):
 Remounting filesystem read-only

--- Comment #8 from Joerg M. Sigle ( ---
Thank you all for your explanations, again.

> Casefold is an 'incompat' feature, because it changes the directory format.
> So if someone enables it (on-disk [...]), old kernels can't use the
> filesystem at all.

Might this not warrant a warning in the ext4/ext5 manpage?
E.g. similar to what is there for the "ext64" feature:

"Note that some older kernels and older versions of e2fsprogs
 will not support file systems with this ext4 feature enabled."

The current text doesn't reveal this:

"[casefold] is name-preserving on the disk, but it
 allows applications to lookup for a file in the file system
 using an encoding equivalent version of the file name."

The required minimum versions of e2fsck, tune2fs etc. might also be mentioned.

> This issue is about how the kernel treats inodes that got corrupted
> to have the casefold flag set when the user didn't actually enable the
> casefold feature. The ext4 feature flags have clear behavior for how
> unexpected flags are handled, but the inode flags don't.

I use ext2 as least common denominator for multiple OS. I use conservative
settings. And still "got caught" by a new (!) disabled (!) opt-in (!) feature,
with hits apparently coming out-of-the-blue, and left without (much of) a clue

So IMHO a system not expected to use certain bits should rather not turn the fs
to r/o because of them. Or, at least, indicate the minimum e2fsck version
needed for fixing.

These bits could, however, still be checked very systematically: by letting
tune2fs  recommend (or even call?) ext2fs whenever a user is about to enable
casefold support on a preexisting fs. Only then, these bits become really
meaningful, the admin is ready, and ext2fs is guaranteed to be sufficiently

Anytime afterwards, once that feature *is* enabled - any form of checking and
reaction by the kernel would be perfectly fine and no bad surprise anymore.

Equally ok: Revelation of the problem by regular scheduled e2fsck runs, once
e2fsck has been sufficiently updated over time to recognize and handle the

Thanks again for your consideration & regards! Joerg

You are receiving this mail because:
You are watching the assignee of the bug.

Powered by blists - more mailing lists