Re: [PATCH 2/4] fscrypt: Validate the test_dummy_encryption policy for new inodes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] fscrypt: missed S_CASEFOLD check in fscrypt_prepare_new_inode()
--

commit fa704dc171d6c1edb5f7cea48ff46447da451c52
Author: Baokun Li <libaokun@linux.alibaba.com>

fscrypt: Validate the test_dummy_encryption policy for new inodes

This commit validates the test_dummy_encryption policy in
fscrypt_prepare_new_inode() when creating a new inode in an unencrypted
directory so that unsupported policies are rejected before being applied.

> diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c
> index a77b889d7578c..497ba67ec6fed 100644
> --- a/fs/crypto/keysetup.c
> +++ b/fs/crypto/keysetup.c
> @@ -763,6 +763,14 @@ int fscrypt_prepare_new_inode(struct inode *dir, struct inode *inode,
>  	    !S_ISLNK(inode->i_mode))
>  		return 0;
>  
> +	/*
> +	 * A policy inherited from an encrypted directory was validated
> +	 * when the directory's key was set up.  The test dummy policy was
> +	 * not, so check it here.
> +	 */
> +	if (!IS_ENCRYPTED(dir) && !fscrypt_supported_policy(policy, inode))
> +		return -EINVAL;

[Severity: Medium]
Does fscrypt_supported_policy(policy, inode) miss the casefold check when
creating a new subdirectory inside an unencrypted, casefolded directory with
test_dummy_encryption=v1?

When fscrypt_prepare_new_inode() is called by __ext4_new_inode() or
f2fs_new_inode(), only inode->i_mode and inode->i_blkbits are set on the new
inode. The filesystem has not yet inherited the casefold flag from dir or set
S_CASEFOLD on inode->i_flags, which is why fscrypt_prepare_new_inode() checks
IS_CASEFOLDED(dir) && S_ISDIR(inode->i_mode) just below:

	return fscrypt_setup_encryption_info(inode, policy, nonce,
					     IS_CASEFOLDED(dir) &&
					     S_ISDIR(inode->i_mode));

However, fscrypt_supported_policy() -> fscrypt_supported_v1_policy() checks
IS_CASEFOLDED(inode):

	if (IS_CASEFOLDED(inode)) {
		/* With v1, there's no way to derive dirhash keys. */
		fscrypt_warn(inode,
			     "v1 policies can't be used on casefolded directories");
		return false;
	}

Since IS_CASEFOLDED(inode) is still false at this point, creating a
subdirectory in an unencrypted casefolded directory under
test_dummy_encryption=v1 passes validation and creates a v1-encrypted,
casefolded directory without an initialized dirhash key, triggering
WARN_ON_ONCE(!ci->ci_dirhash_key_initialized) in fscrypt_fname_siphash() on
subsequent lookups or creations.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103153132.4154855-1-libaokun@linux.alibaba.com?part=2