linux-ext4 - Re: generic/454 regression in 6.2-rc1

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]

Message-Id: <7DE6598D-B60D-466F-8771-5FEC0FDEC57F@dilger.ca>
Date:   Tue, 17 Jan 2023 17:10:55 -0700
From:   Andreas Dilger <adilger@...ger.ca>
To:     Eric Whitney <enwlinux@...il.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: generic/454 regression in 6.2-rc1

On Jan 17, 2023, at 11:31 AM, Eric Whitney <enwlinux@...il.com> wrote:
> 
> My 6.2-rc1 regression run on the current x86-64 test appliance revealed a new
> failure for generic/454 on the 4k file system configuration and all other
> configurations using a 4k block size.  This failure reproduces with 100%
> reliability and continues to appear as of 6.2-rc4.
> 
> The test output indicates that the file system under test is inconsistent.

There is actually support in the superblock for both signed and unsigned char
hash calculations, exactly because there was a bug like this in the past.
It looks like the ext4 code/build is still using the signed hash functions:


static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb)
{
	:
	:
                if (i & EXT2_FLAGS_UNSIGNED_HASH)
                        sbi->s_hash_unsigned = 3;
                else if ((i & EXT2_FLAGS_SIGNED_HASH) == 0) {
#ifdef __CHAR_UNSIGNED__
                        if (!sb_rdonly(sb))
                                es->s_flags |=
                                        cpu_to_le32(EXT2_FLAGS_UNSIGNED_HASH);
                        sbi->s_hash_unsigned = 3;
#else
                        if (!sb_rdonly(sb))
                                es->s_flags |=
                                        cpu_to_le32(EXT2_FLAGS_SIGNED_HASH);
#endif
                }

It looks like this *should* be detecting the unsigned/signed char type
automatically based on __CHAR_UNSIGNED__, but that isn't working properly
in this case.  I have no idea whether this is a compiler or kernel issue,
just thought I'd point out the background of what ext4 is doing here.

Cheers, Andreas

> e2fsck reports:
> 
> *** fsck.ext4 output ***
> fsck from util-linux 2.36.1
> e2fsck 1.46.2 (28-Feb-2021)
> Pass 1: Checking inodes, blocks, and sizes
> Extended attribute in inode 131074 has a hash (857950233) which is invalid
> Clear? no
> 
> Extended attribute in inode 131074 has a hash (736302368) which is invalid
> Clear? no
> 
> Extended attribute in inode 131074 has a hash (674453032) which is invalid
> Clear? no
> 
> Extended attribute in inode 131074 has a hash (2299266654) which is invalid
> Clear? no
> 
> Extended attribute in inode 131074 has a hash (3503002490) which is invalid
> Clear? no
> 
> < and continues with more of the same >
> 
> The failure bisects to the following commit in -rc1:
> 
> 3bc753c06dd0 ("kbuild: treat char as always unsigned")
> 
> The comment for this commit suggests that it's likely to cause things to
> break where there has been type misuse for char;  presumably, that's what's
> happened here.
> 
> Eric
> 


Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)