Lizhi Xu [off-list ref] writes:

On Mon, 03 Jun 2024 10:50:51 -0400, Gabriel Krisman Bertazi wrote:

quoted

quoted

When mounting the ext4 filesystem, if the hash version and casefolded are not
consistent, exit the mounting.

Reported-by: syzbot+340581ba9dceb7e06fb3@syzkaller.appspotmail.com
Signed-off-by: Lizhi Xu <redacted>
---
 fs/ext4/super.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index c682fb927b64..0ad326504c50 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c

@@ -5262,6 +5262,11 @@ static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb)
 		goto failed_mount;
 
 	ext4_hash_info_init(sb);
+	if (es->s_def_hash_version == DX_HASH_SIPHASH && 
+	    !ext4_has_feature_casefold(sb)) {

Can we ever have DX_HASH_SIPHASH set up in the super block?  I thought
it was used solely for directories where ext4_hash_in_dirent(inode) is
true.

The value of s'def_hash_version is obtained by reading the super block from the
buffer cache of the block device in ext4_load_super().

Yes, I know.  My point is whether this check should just be:

if (es->s_def_hash_version == DX_HASH_SIPHASH)
	goto failed_mount;

Since, IIUC, DX_HASH_SIPHASH is done per-directory and not written to
the sb.

quoted

If this is only for the case of a superblock corruption, perhaps we
should always reject the mount, whether casefold is enabled or not?

Based on the existing information, it cannot be confirmed whether the superblock
is corrupt, but one thing is clear: if the default hash version of the superblock
is set to DX_HASH_SIPHASH, but the casefold feature is not set at the same time,
it is definitely an error.

-- 
Gabriel Krisman Bertazi