Re: [PATCH v1] ecryptfs: validate key payload size and session key length

[Tyler Hicks <code@tyhicks.com>]

On 2026-10-03 20:46:08, Svyatoslav Nikolenko wrote:
> Syzkaller reported an out-of-bounds read, which sometimes manifests as a
> slab-use-after-free, in ecryptfs_write_tag_70_packet(). This is caused by
> two structural validation failures when handling malformed user keys.
> 
> First, eCryptfs blindly casts the user key payload into a
> `struct ecryptfs_auth_tok` without verifying the physical size of the
> allocation. If a user provides a key that is significantly smaller than
> sizeof(struct ecryptfs_auth_tok), accessing struct fields located deep
> within the memory layout (such as `session_key_encryption_key_bytes`)
> forces the kernel to read past the end of the allocated slab object. If
> the adjacent slab object was recently freed, KASAN reports this as a
> use-after-free.
> 
> Second, eCryptfs does not validate the internal length field
> `session_key_encryption_key_bytes` before passing it to md5().
> A maliciously large value causes md5() to read out of bounds.
> 
> Fix this by explicitly checking the user_key_payload `datalen` to ensure
> the physical memory is large enough to hold the expected structure, and
> subsequently bounding `session_key_encryption_key_bytes` to the actual
> size of the `session_key_encryption_key` array.
> 
> Reported-by: syzbot+46bbbe175b7eea8036b8@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=46bbbe175b7eea8036b8
> Tested-by: syzbot+46bbbe175b7eea8036b8@syzkaller.appspotmail.com
> Fixes: 0bbb838f385a ("ecryptfs: Use MD5 library instead of crypto_shash")
> Signed-off-by: Svyatoslav Nikolenko <nsvatoslav515@gmail.com>

Hello and thank you for the patch! Unfortunately, these checks are added
in the wrong place to protect other packet types (like tag 3). I've
already taken the user key payload fix from another contributor and will
take the session key encryption key check from a separate contributor.
You can find the links here:

 * https://lore.kernel.org/ecryptfs/20260917044558.41677-1-neganhat@gmail.com/
 * https://lore.kernel.org/ecryptfs/20261004123755.14642-1-adrianox@gmail.com/

Thanks again for taking the time to submit a patch!

Tyler

> ---
>  fs/ecryptfs/keystore.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/fs/ecryptfs/keystore.c b/fs/ecryptfs/keystore.c
> index 51651314b7a6..b2fd238bcd97 100644
> --- a/fs/ecryptfs/keystore.c
> +++ b/fs/ecryptfs/keystore.c
> @@ -621,6 +621,7 @@ ecryptfs_write_tag_70_packet(char *dest, size_t *remaining_bytes,
>  {
>  	struct ecryptfs_write_tag_70_packet_silly_stack *s;
>  	struct key *auth_tok_key = NULL;
> +	struct user_key_payload *ukp;
>  	int rc = 0;
>  
>  	s = kzalloc_obj(*s);
> @@ -738,6 +739,20 @@ ecryptfs_write_tag_70_packet(char *dest, size_t *remaining_bytes,
>  		goto out_free_unlock;
>  	}
>  
> +	ukp = user_key_payload_locked(auth_tok_key);
> +	if (!ukp || ukp->datalen < sizeof(struct ecryptfs_auth_tok)) {
> +		printk(KERN_ERR "Error key payload too small\n");
> +		rc = -EINVAL;
> +		goto out_free_unlock;
> +	}
> +
> +	if (s->auth_tok->token.password.session_key_encryption_key_bytes >
> +			sizeof(s->auth_tok->token.password.session_key_encryption_key)) {
> +		printk(KERN_ERR "Error FNEK key size too large\n");
> +		rc = -EINVAL;
> +		goto out_free_unlock;
> +	}
> +
>  	md5(s->auth_tok->token.password.session_key_encryption_key,
>  	    s->auth_tok->token.password.session_key_encryption_key_bytes,
>  	    s->hash);
> -- 
> 2.47.3
>