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.
Lizhi
