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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox