On Mon, Apr 10, 2023 at 03:39:59PM -0400, Sweet Tea Dorminy wrote:
> diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c
> index 8b32200dbbc0..f07e3b9579cf 100644
> --- a/fs/crypto/keysetup.c
> +++ b/fs/crypto/keysetup.c
> @@ -181,7 +181,11 @@ void fscrypt_destroy_prepared_key(struct super_block *sb,
> int fscrypt_set_per_file_enc_key(struct fscrypt_info *ci, const u8 *raw_key)
> {
> ci->ci_owns_key = true;
> - return fscrypt_prepare_key(&ci->ci_enc_key, raw_key, ci);
> + ci->ci_enc_key = kzalloc(sizeof(*ci->ci_enc_key), GFP_KERNEL);
> + if (!ci->ci_enc_key)
> + return -ENOMEM;
> +
> + return fscrypt_prepare_key(ci->ci_enc_key, raw_key, ci);
> }
Any idea how much this will increase the per-inode memory usage by, in the
per-file keys case? (Counting the overhead of the slab allocator.)
> - else if (ci->ci_owns_key)
> + else if (ci->ci_owns_key) {
> fscrypt_destroy_prepared_key(ci->ci_inode->i_sb,
> - &ci->ci_enc_key);
> + ci->ci_enc_key);
> + kfree(ci->ci_enc_key);
Use kfree_sensitive() here, please. Yes, it's not actually needed here because
the allocation doesn't contain the keys themselves. But I want to code
defensively here.
- Eric
|