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