On Thu, Aug 21, 2008 at 07:02:25AM +0000, Sascha Biberhofer wrote:
> I have the same problem on my system, starting with the release of
> 2.6.26. Shortly afterwards I've had the same problem with the 2.6.25
> series starting with 2.6.25.12. I've looked up the changes between
> 2.6.25.11 and .12 and found commit
> c2bd04d8040a91fe2ee2e9fee1a6562ca9792249 (it's commit
> 872ac8743cb400192a9fce4ba2d3ffd7bb309685 in the 2.6.26 series).
> Reverting the commit seems to solve the problem here, I've been running
> a 2.6.25.12 kernel without this commit for some weeks now.
> In case it's important: I'm using an IPSec ESP transport with AES-256
> and sha-256 auth.
Sorry, I was skimping on memory and ended up calling a clobbered
function pointer.
This patch should fix it.
crypto: authenc - Avoid using clobbered request pointer
Authenc works in two stages for encryption, it first encrypts and
then computes an ICV. The context memory of the request is used
by both operations. The problem is that when an asynchronous
encryption completes, we will compute the ICV and then reread the
context memory of the encryption to get the original request.
It just happens that we have a buffer of 16 bytes in front of the
request pointer, so ICVs of 16 bytes (such as SHA1) do not trigger
the bug. However, any attempt to uses a larger ICV instantly kills
the machine when the first asynchronous encryption is completed.
This patch fixes this by saving the request pointer before we start
the ICV computation.
Signed-off-by: Herbert Xu <[email protected]>
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/crypto/authenc.c b/crypto/authenc.c
index 4b22676..fd9f06c 100644
--- a/crypto/authenc.c
+++ b/crypto/authenc.c
@@ -174,8 +174,9 @@ static int crypto_authenc_genicv(struct aead_request *req, u8 *iv,
static void crypto_authenc_encrypt_done(struct crypto_async_request *req,
int err)
{
+ struct aead_request *areq = req->data;
+
if (!err) {
- struct aead_request *areq = req->data;
struct crypto_aead *authenc = crypto_aead_reqtfm(areq);
struct crypto_authenc_ctx *ctx = crypto_aead_ctx(authenc);
struct ablkcipher_request *abreq = aead_request_ctx(areq);
@@ -185,7 +186,7 @@ static void crypto_authenc_encrypt_done(struct crypto_async_request *req,
err = crypto_authenc_genicv(areq, iv, 0);
}
- aead_request_complete(req->data, err);
+ aead_request_complete(areq, err);
}
static int crypto_authenc_encrypt(struct aead_request *req)
@@ -216,14 +217,15 @@ static int crypto_authenc_encrypt(struct aead_request *req)
static void crypto_authenc_givencrypt_done(struct crypto_async_request *req,
int err)
{
+ struct aead_request *areq = req->data;
+
if (!err) {
- struct aead_request *areq = req->data;
struct skcipher_givcrypt_request *greq = aead_request_ctx(areq);
err = crypto_authenc_genicv(areq, greq->giv, 0);
}
- aead_request_complete(req->data, err);
+ aead_request_complete(areq, err);
}
static int crypto_authenc_givencrypt(struct aead_givcrypt_request *req)
On Thu, 21 Aug 2008 18:36:15 +1000
Herbert Xu <[email protected]> wrote:
> On Thu, Aug 21, 2008 at 07:02:25AM +0000, Sascha Biberhofer wrote:
> > I have the same problem on my system, starting with the release of
> > 2.6.26. Shortly afterwards I've had the same problem with the 2.6.25
> > series starting with 2.6.25.12. I've looked up the changes between
> > 2.6.25.11 and .12 and found commit
> > c2bd04d8040a91fe2ee2e9fee1a6562ca9792249 (it's commit
> > 872ac8743cb400192a9fce4ba2d3ffd7bb309685 in the 2.6.26 series).
> > Reverting the commit seems to solve the problem here, I've been running
> > a 2.6.25.12 kernel without this commit for some weeks now.
> > In case it's important: I'm using an IPSec ESP transport with AES-256
> > and sha-256 auth.
>
> Sorry, I was skimping on memory and ended up calling a clobbered
> function pointer.
>
> This patch should fix it.
>
> crypto: authenc - Avoid using clobbered request pointer
>
> Authenc works in two stages for encryption, it first encrypts and
> then computes an ICV. The context memory of the request is used
> by both operations. The problem is that when an asynchronous
> encryption completes, we will compute the ICV and then reread the
> context memory of the encryption to get the original request.
>
> It just happens that we have a buffer of 16 bytes in front of the
> request pointer, so ICVs of 16 bytes (such as SHA1) do not trigger
> the bug. However, any attempt to uses a larger ICV instantly kills
> the machine when the first asynchronous encryption is completed.
>
> This patch fixes this by saving the request pointer before we start
> the ICV computation.
>
> Signed-off-by: Herbert Xu <[email protected]>
Acked-by: Matt LaPlante <[email protected]>
Thanks for the quick fix!
--
Matt LaPlante
Cc: [email protected] ?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Thu, Aug 21, 2008 at 11:56:10AM -0300, Henrique de Moraes Holschuh wrote:
> Cc: [email protected] ?
Once it's merged by Linus I'll push it to stable.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Herbert Xu wrote:
> Sorry, I was skimping on memory and ended up calling a clobbered
> function pointer.
>
> This patch should fix it.
Works like a charm, thanks for the quick fix.
Sascha Biberhofer