• R/O
  • HTTP
  • SSH
  • HTTPS

linux-2.4.36: コミット

2.4.36-stable kernel tree


コミットメタ情報

リビジョンaf30313f5d14531bff3df468e2c59cff15b2d5a0 (tree)
日時2006-08-27 20:51:31
作者Solar Designer <solar@open...>
コミッターWilly Tarreau

ログメッセージ

[PATCH] crypto : prevent cryptoloop from oopsing on stupid ciphers

With the cryptoloop patch applied, it's possible to request
ECB mode encryption, which will result in a Oops because of
uninitialized function pointers. Initializing them to the
nocrypt_iv() function does not completely solve the problem
because cryptoloop does not check the return code, and kernel
memory will leak uninitialized through cryptoloop.

Proposed solution :

Can we maybe define working but IV-ignoring functions for ECB (like I
did), but use memory-clearing nocrypt*() for CFB and CTR (as long as
these are not supported)? Of course, all of these will return -ENOSYS.

Response from Herbert Xu :

In cryptodev-2.6, with block ciphers you can no longer select CFB/CTR
until someone writes support for them so this is no longer an issue.
For 2.4, I don't really mind either way what nocrypt does.

Final solution :

OK, I've merged Willy's suggestion for the memset()s into the patch
that I had submitted previously. The resulting patch is attached.

変更サマリ

差分

--- a/crypto/cipher.c
+++ b/crypto/cipher.c
@@ -147,6 +147,15 @@ static int ecb_encrypt(struct crypto_tfm *tfm,
147147 ecb_process, 1, NULL);
148148 }
149149
150+static int ecb_encrypt_iv(struct crypto_tfm *tfm,
151+ struct scatterlist *dst,
152+ struct scatterlist *src,
153+ unsigned int nbytes, u8 *iv)
154+{
155+ ecb_encrypt(tfm, dst, src, nbytes);
156+ return -ENOSYS;
157+}
158+
150159 static int ecb_decrypt(struct crypto_tfm *tfm,
151160 struct scatterlist *dst,
152161 struct scatterlist *src,
@@ -157,6 +166,15 @@ static int ecb_decrypt(struct crypto_tfm *tfm,
157166 ecb_process, 1, NULL);
158167 }
159168
169+static int ecb_decrypt_iv(struct crypto_tfm *tfm,
170+ struct scatterlist *dst,
171+ struct scatterlist *src,
172+ unsigned int nbytes, u8 *iv)
173+{
174+ ecb_decrypt(tfm, dst, src, nbytes);
175+ return -ENOSYS;
176+}
177+
160178 static int cbc_encrypt(struct crypto_tfm *tfm,
161179 struct scatterlist *dst,
162180 struct scatterlist *src,
@@ -197,11 +215,20 @@ static int cbc_decrypt_iv(struct crypto_tfm *tfm,
197215 cbc_process, 0, iv);
198216 }
199217
218+/*
219+ * nocrypt*() zeroize the destination buffer to make sure we don't leak
220+ * uninitialized memory contents if the caller ignores the return value.
221+ * This is bad since the data in the source buffer is unused and may be
222+ * lost, but an infoleak would be even worse. The performance cost of
223+ * memset() is irrelevant since a well-behaved caller would not bump into
224+ * the error repeatedly.
225+ */
200226 static int nocrypt(struct crypto_tfm *tfm,
201227 struct scatterlist *dst,
202228 struct scatterlist *src,
203229 unsigned int nbytes)
204230 {
231+ memset(dst, 0, nbytes);
205232 return -ENOSYS;
206233 }
207234
@@ -210,6 +237,7 @@ static int nocrypt_iv(struct crypto_tfm *tfm,
210237 struct scatterlist *src,
211238 unsigned int nbytes, u8 *iv)
212239 {
240+ memset(dst, 0, nbytes);
213241 return -ENOSYS;
214242 }
215243
@@ -235,6 +263,11 @@ int crypto_init_cipher_ops(struct crypto_tfm *tfm)
235263 case CRYPTO_TFM_MODE_ECB:
236264 ops->cit_encrypt = ecb_encrypt;
237265 ops->cit_decrypt = ecb_decrypt;
266+/* These should have been nocrypt_iv, but patch-cryptoloop-jari-2.4.22.0
267+ * (and its other revisions) directly calls the *_iv() functions even in
268+ * ECB mode and ignores their return value. */
269+ ops->cit_encrypt_iv = ecb_encrypt_iv;
270+ ops->cit_decrypt_iv = ecb_decrypt_iv;
238271 break;
239272
240273 case CRYPTO_TFM_MODE_CBC:
旧リポジトリブラウザで表示