EcryptFS development
 help / color / mirror / Atom feed
From: Jay Vadayath <jay@artiphishell.com>
To: Tyler Hicks <code@tyhicks.com>
Cc: ecryptfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jay Vadayath <jay@artiphishell.com>
Subject: [PATCH] fs/ecryptfs: fix slab-out-of-bounds write when decrypting session key
Date: Mon, 20 Jul 2026 11:11:39 -0700	[thread overview]
Message-ID: <20260720181140.8512-1-jay@artiphishell.com> (raw)

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>

---
 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-20 18:11 UTC|newest]

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

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=20260720181140.8512-1-jay@artiphishell.com \
    --to=jay@artiphishell.com \
    --cc=code@tyhicks.com \
    --cc=ecryptfs@vger.kernel.org \
    --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