linux-kernel - Re: CRYPTO xcbc: Fix crash when ipsec uses xcbc-mac with big data chunk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080417142259.GA12808@gondor.apana.org.au>
Date:	Thu, 17 Apr 2008 22:22:59 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	S.Çağlar Onur <caglar@...dus.org.tr>
Cc:	Chris Wright <chrisw@...s-sol.org>, linux-kernel@...r.kernel.org,
	stable@...nel.org, Justin Forbes <jmforbes@...uxtx.org>,
	Zwane Mwaikambo <zwane@....linux.org.uk>,
	Theodore Ts'o <tytso@....edu>,
	Randy Dunlap <rdunlap@...otime.net>,
	Dave Jones <davej@...hat.com>,
	Chuck Wolber <chuckw@...ntumlinux.com>,
	Chris Wedgwood <reviews@...cw.f00f.org>,
	Michael Krufky <mkrufky@...uxtv.org>,
	Chuck Ebbert <cebbert@...hat.com>,
	Domenico Andreoli <cavokz@...il.com>,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk, Joy Latten <latten@...tin.ibm.com>
Subject: Re: CRYPTO xcbc: Fix crash when ipsec uses xcbc-mac with big data chunk

On Thu, Apr 17, 2008 at 02:26:12PM +0300, S.Çağlar Onur wrote:
>
>   CC [M]  crypto/xcbc.o
> crypto/xcbc.c: In function `crypto_xcbc_digest_update2':
> crypto/xcbc.c:186: error: implicit declaration of function `scatterwalk_sg_next'
> crypto/xcbc.c:186: warning: assignment makes pointer from integer without a cast
> make[1]: *** [crypto/xcbc.o] Hata 1
> make: *** [crypto] Hata 2

Sorry, my fault.  That should've been sg_next for 2.6.24.

Thanks for catching this!
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
From: Joy Latten <latten@...tin.ibm.com>

[CRYPTO] xcbc: Fix crash when ipsec uses xcbc-mac with big data chunk

[ Upstream commit: 1edcf2e1ee2babb011cfca80ad9d202e9c491669 ]

The kernel crashes when ipsec passes a udp packet of about 14XX bytes
of data to aes-xcbc-mac.

It seems the first xxxx bytes of the data are in first sg entry,
and remaining xx bytes are in next sg entry. But we don't
check next sg entry to see if we need to go look the page up.

I noticed in hmac.c, we do a scatterwalk_sg_next(), to do this check
and possible lookup, thus xcbc.c needs to use this routine too.

A 15-hour run of an ipsec stress test sending streams of tcp and
udp packets of various sizes,  using this patch and
aes-xcbc-mac completed successfully, so hopefully this fixes the
problem.

Signed-off-by: Joy Latten <latten@...tin.ibm.com>
Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>

diff --git a/crypto/xcbc.c b/crypto/xcbc.c
index 2feb0f2..b63b633 100644
--- a/crypto/xcbc.c
+++ b/crypto/xcbc.c
@@ -116,13 +116,11 @@ static int crypto_xcbc_digest_update2(struct hash_desc *pdesc,
 	struct crypto_xcbc_ctx *ctx = crypto_hash_ctx_aligned(parent);
 	struct crypto_cipher *tfm = ctx->child;
 	int bs = crypto_hash_blocksize(parent);
-	unsigned int i = 0;
 
-	do {
-
-		struct page *pg = sg_page(&sg[i]);
-		unsigned int offset = sg[i].offset;
-		unsigned int slen = sg[i].length;
+	for (;;) {
+		struct page *pg = sg_page(sg);
+		unsigned int offset = sg->offset;
+		unsigned int slen = sg->length;
 
 		if (unlikely(slen > nbytes))
 			slen = nbytes;
@@ -182,8 +180,11 @@ static int crypto_xcbc_digest_update2(struct hash_desc *pdesc,
 			offset = 0;
 			pg++;
 		}
-		i++;
-	} while (nbytes>0);
+
+		if (!nbytes)
+			break;
+		sg = sg_next(sg);
+	}
 
 	return 0;
 }

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/