public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: fstests@vger.kernel.org
Cc: linux-fscrypt@vger.kernel.org
Subject: [xfstests PATCH] fscrypt-crypt-util: fix maximum IV size
Date: Sat, 14 Nov 2020 19:15:36 -0800	[thread overview]
Message-ID: <20201115031536.1469955-1-ebiggers@kernel.org> (raw)

From: Eric Biggers <ebiggers@google.com>

In commit 65cd8e8a8e81 ("fscrypt-crypt-util: fix IV incrementing for
--iv-ino-lblk-32") I mistakenly decreased the size of fscrypt_iv to 24
bytes, which is the most that is explicitly needed by any of the IV
generation methods.  However, Adiantum encryption takes a 32-byte IV, so
the buffer still needs to be 32 bytes, with any extra bytes zeroed.

So restore the size to 32 bytes.

This fixes a buffer overread that caused generic/550 and generic/584 to
sometimes fail, depending on the build of the fscrypt-crypt-util binary.
(Most of the time it still worked by chance.)

Fixes: 65cd8e8a8e81 ("fscrypt-crypt-util: fix IV incrementing for --iv-ino-lblk-32")
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 src/fscrypt-crypt-util.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/fscrypt-crypt-util.c b/src/fscrypt-crypt-util.c
index 26698d7a..03cc3c4a 100644
--- a/src/fscrypt-crypt-util.c
+++ b/src/fscrypt-crypt-util.c
@@ -1642,6 +1642,7 @@ static u64 siphash_1u64(const u64 key[2], u64 data)
 #define FILE_NONCE_SIZE		16
 #define UUID_SIZE		16
 #define MAX_KEY_SIZE		64
+#define MAX_IV_SIZE		ADIANTUM_IV_SIZE
 
 static const struct fscrypt_cipher {
 	const char *name;
@@ -1715,6 +1716,8 @@ union fscrypt_iv {
 		/* IV_INO_LBLK_64: inode number */
 		__le32 inode_number;
 	};
+	/* Any extra bytes up to the algorithm's IV size must be zeroed */
+	u8 bytes[MAX_IV_SIZE];
 };
 
 static void crypt_loop(const struct fscrypt_cipher *cipher, const u8 *key,
@@ -1736,9 +1739,9 @@ static void crypt_loop(const struct fscrypt_cipher *cipher, const u8 *key,
 		memset(&buf[res], 0, crypt_len - res);
 
 		if (decrypting)
-			cipher->decrypt(key, (u8 *)iv, buf, buf, crypt_len);
+			cipher->decrypt(key, iv->bytes, buf, buf, crypt_len);
 		else
-			cipher->encrypt(key, (u8 *)iv, buf, buf, crypt_len);
+			cipher->encrypt(key, iv->bytes, buf, buf, crypt_len);
 
 		full_write(STDOUT_FILENO, buf, crypt_len);
 
-- 
2.29.2


                 reply	other threads:[~2020-11-15  3:16 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20201115031536.1469955-1-ebiggers@kernel.org \
    --to=ebiggers@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-fscrypt@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