EcryptFS development
 help / color / mirror / Atom feed
From: Tyler Hicks <code@tyhicks.com>
To: Jay Vadayath <jay@artiphishell.com>
Cc: ecryptfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	HanQuan <eilaimemedsnaimel@gmail.com>
Subject: Re: [PATCH] fs/ecryptfs: fix slab-out-of-bounds write when decrypting session key
Date: Tue, 21 Jul 2026 02:35:26 -0500	[thread overview]
Message-ID: <al8hPqCTYlYAkiPP@elm> (raw)
In-Reply-To: <20260720181140.8512-1-jay@artiphishell.com>

On 2026-07-20 11:11:39, Jay Vadayath wrote:
> parse_tag_3_packet() only bounds the Tag 3 encrypted key size against
> ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES (512), but
> decrypt_passphrase_encrypted_session_key() decrypts that many bytes
> straight into the fixed-size auth_tok->session_key.decrypted_key buffer,
> which is only ECRYPTFS_MAX_KEY_BYTES (64) bytes long. A crafted lower
> file whose Tag 3 packet advertises an encrypted key larger than 64 bytes
> therefore causes the cipher to write past the end of the decrypted_key
> buffer (and past the ecryptfs_auth_tok_list_item slab object).
> 
> KASAN report from opening a crafted eCryptfs file as an unprivileged
> user:
> 
>   BUG: KASAN: slab-out-of-bounds in aes_decrypt+0x1587/0x1640
>   Write of size 4 at addr ffff88800616af38 by task poc/115
>   Call Trace:
>    dump_stack_lvl+0x64/0x80
>    print_report+0xce/0x620
>    kasan_report+0xec/0x120
>    aes_decrypt+0x1587/0x1640
>    crypto_ecb_decrypt2+0xe9/0x150
>    crypto_lskcipher_crypt_sg+0x233/0x360
>    decrypt_passphrase_encrypted_session_key+0x4b9/0xb00
>    ecryptfs_parse_packet_set+0x5d6/0x1d70
>    ecryptfs_read_metadata+0x102/0x430
>    ecryptfs_open+0x274/0x5f0
>    do_dentry_open+0x401/0x1280
>    vfs_open+0x74/0x350
>    path_openat+0x23e7/0x3eb0
>    do_file_open+0x1ef/0x450
>    do_sys_openat2+0xd7/0x170
>    __x64_sys_openat+0x133/0x1d0
>    do_syscall_64+0x107/0x5a0
>    entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> Reject encrypted key sizes that exceed the size of the decrypted_key
> buffer before performing the decryption.
> 
> This bug was discovered by Artiphishell's vTriage pipeline, which
> generated a userspace reproducer (opening a crafted lower file) that
> reliably triggers the KASAN report on an unpatched kernel. The fix
> below was drafted with the Claude coding assistant; a userspace
> reproducer is available on request.
> 
> Assisted-by: Claude:claude-opus-4-7
> Signed-off-by: Jay Vadayath <jay@artiphishell.com>

Hello Jay - thank you for the report and fix! This issue has already
been reported by HanQuan and I've pushed the fix to the ecryptfs next
branch:

 ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet
 https://git.kernel.org/tyhicks/ecryptfs/c/5babe9c177c364521e3e682b949c5a8c47f4a441

We opted to fix it a little bit different than your patch. Please take a
look at it to see if you spot any issues. Thanks!

Tyler

> 
> ---
>  fs/ecryptfs/keystore.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> --- a/fs/ecryptfs/keystore.c
> +++ b/fs/ecryptfs/keystore.c
> @@ -1615,6 +1615,14 @@ decrypt_passphrase_encrypted_session_key(struct ecryptfs_auth_tok *auth_tok,
>  	struct skcipher_request *req = NULL;
>  	int rc = 0;
> 
> +	if (auth_tok->session_key.encrypted_key_size > ECRYPTFS_MAX_KEY_BYTES) {
> +		printk(KERN_WARNING "%s: Encrypted key size [%d] is larger than "
> +		       "the maximum decrypted key size [%d]\n", __func__,
> +		       auth_tok->session_key.encrypted_key_size,
> +		       ECRYPTFS_MAX_KEY_BYTES);
> +		rc = -EINVAL;
> +		goto out;
> +	}
>  	if (unlikely(ecryptfs_verbosity > 0)) {
>  		ecryptfs_printk(
>  			KERN_DEBUG, "Session key encryption key (size [%d]):\n",

      reply	other threads:[~2026-07-21  7:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20 18:11 [PATCH] fs/ecryptfs: fix slab-out-of-bounds write when decrypting session key Jay Vadayath
2026-07-21  7:35 ` Tyler Hicks [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=al8hPqCTYlYAkiPP@elm \
    --to=code@tyhicks.com \
    --cc=ecryptfs@vger.kernel.org \
    --cc=eilaimemedsnaimel@gmail.com \
    --cc=jay@artiphishell.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox