netdev - Re: [PATCH] xfrm: Perform a replay check after return from async codepaths

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: <20110921115727.GX1808@secunet.com>
Date:	Wed, 21 Sep 2011 13:57:27 +0200
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] xfrm: Perform a replay check after return from async
 codepaths

On Wed, Sep 21, 2011 at 09:21:58PM +1000, Herbert Xu wrote:
> On Wed, Sep 21, 2011 at 11:38:58AM +0200, Steffen Klassert wrote:
> > When asyncronous crypto algorithms are used, there might be many
> > packets that passed the xfrm replay check, but the replay advance
> > function is not called yet for these packets. So the replay check
> > function would accept a replay of all of these packets. Also the
> > system might crash if there are more packets in async processing
> > than the size of the anti replay window, because the replay advance
> > function would try to update the replay window beyond the bounds.
> > 
> > This pach adds a second replay check after resuming from the async
> > processing to fix these issues.
> > 
> > Signed-off-by: Steffen Klassert <steffen.klassert@...unet.com>
> 
> Actually why does this matter? For a single SA, the processing
> in xfrm_input should be completely synchronous, even when you're
> using asynchronous algorithms.
> 

Well, I've got pretty reproduceable crashes when the sender of
the IPsec packets introduces reorder, that's why I noticed this.

The problem is, that the replay check function is called before
the asynchronous crypto processing and the replay advance function
is called after resume from the asynchronous processing. So
we can submit multiple packets to the crypto layer without
updating the replay window. This means that the replay check
function accepts packets that should have been dropped, because
they are reordered and more than 'replay window size' packets
to late. This leads to a crash as we try to update the replay
window beyond the allocated bounds.
--
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