netdev - Re: Oops in authenc: 2.6.26.3

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: <20080821080811.8a834a46.kernel1@cyberdogtech.com>
Date:	Thu, 21 Aug 2008 08:08:11 -0500
From:	Matt LaPlante <kernel1@...erdogtech.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	Sascha Biberhofer <biberhofer@...de.at>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	netdev@...r.kernel.org,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: Oops in authenc: 2.6.26.3

On Thu, 21 Aug 2008 18:36:15 +1000
Herbert Xu <herbert@...dor.apana.org.au> 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 <herbert@...dor.apana.org.au>

Acked-by: Matt LaPlante <kernel1@...erdogtech.com>

Thanks for the quick fix!

-- 
Matt LaPlante

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html