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",
prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.