On Fri, May 31, 2024 at 09:47:47AM +0800, 'Lizhi Xu' via syzkaller-bugs wrote:
> On Thu, 30 May 2024 18:05:13 -0700, Eric Biggers wrote:
> > > The file name that needs to calculate the siphash must have both flags casefolded
> > > and dir at the same time, so before calculating it, confirm that the flag meets
> > > the conditions.
> > >
> > > Reported-by: syzbot+340581ba9dceb7e06fb3@xxxxxxxxxxxxxxxxxxxxxxxxx
> > > Signed-off-by: Lizhi Xu <lizhi.xu@xxxxxxxxxxxxx>
> > > ---
> > > fs/ext4/hash.c | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/fs/ext4/hash.c b/fs/ext4/hash.c
> > > index deabe29da7fb..c8840cfc01dd 100644
> > > --- a/fs/ext4/hash.c
> > > +++ b/fs/ext4/hash.c
> > > @@ -265,6 +265,10 @@ static int __ext4fs_dirhash(const struct inode *dir, const char *name, int len,
> > > __u64 combined_hash;
> > >
> > > if (fscrypt_has_encryption_key(dir)) {
> > > + if (!IS_CASEFOLDED(dir)) {
> > > + ext4_warning_inode(dir, "Siphash requires Casefolded file");
> > > + return -2;
> > > + }
> > > combined_hash = fscrypt_fname_siphash(dir, &qname);
> > > } else {
> > > ext4_warning_inode(dir, "Siphash requires key");
> >
> > First, this needs to be sent to the ext4 mailing list (and not to irrelevant
> > mailing lists such as netdev). Please use ./scripts/get_maintainer.pl, as is
> > recommended by Documentation/process/submitting-patches.rst.
> >
> > Second, ext4 already checks for the directory being casefolded before allowing
> > siphash. This is done by dx_probe(). Evidently syzbot found some way around
> > that, so what needs to be done is figure out why that happened and what is the
> > best fix to prevent it. This is not necessarily the patch you've proposed, as
> > the real issue might actually be a missing check at some earlier time like when
> > reading the inode from disk or when mounting the filesystem.
> I have confirmed that there is no casefolded feature when creating the directory.
> I agree with your statement that it should be checked for casefold features when
> mounting or reading from disk.
>
I haven't looked at the syzbot reproducer, but I'm guessing that the
DX_HASH_SIPHASH is coming from s_def_hash_version in the filesystem superblock.
It's not valid to have DX_HASH_SIPHASH there, and it probably would make more
sense to validate that at mount time.
- Eric
