* [PATCH] xfrm: Perform a replay check after return from async codepaths
@ 2011-09-21 9:38 Steffen Klassert
2011-09-21 11:21 ` Herbert Xu
0 siblings, 1 reply; 5+ messages in thread
From: Steffen Klassert @ 2011-09-21 9:38 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, netdev
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@secunet.com>
---
net/xfrm/xfrm_input.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index a026b0e..54a0dc2 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -212,6 +212,11 @@ resume:
/* only the first xfrm gets the encap type */
encap_type = 0;
+ if (async && x->repl->check(x, skb, seq)) {
+ XFRM_INC_STATS(net, LINUX_MIB_XFRMINSTATESEQERROR);
+ goto drop_unlock;
+ }
+
x->repl->advance(x, seq);
x->curlft.bytes += skb->len;
--
1.7.0.4
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] xfrm: Perform a replay check after return from async codepaths
2011-09-21 9:38 [PATCH] xfrm: Perform a replay check after return from async codepaths Steffen Klassert
@ 2011-09-21 11:21 ` Herbert Xu
2011-09-21 11:57 ` Steffen Klassert
0 siblings, 1 reply; 5+ messages in thread
From: Herbert Xu @ 2011-09-21 11:21 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, netdev
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@secunet.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.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] xfrm: Perform a replay check after return from async codepaths
2011-09-21 11:21 ` Herbert Xu
@ 2011-09-21 11:57 ` Steffen Klassert
2011-09-21 12:24 ` Herbert Xu
0 siblings, 1 reply; 5+ messages in thread
From: Steffen Klassert @ 2011-09-21 11:57 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Miller, netdev
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@secunet.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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] xfrm: Perform a replay check after return from async codepaths
2011-09-21 11:57 ` Steffen Klassert
@ 2011-09-21 12:24 ` Herbert Xu
2011-09-21 19:21 ` David Miller
0 siblings, 1 reply; 5+ messages in thread
From: Herbert Xu @ 2011-09-21 12:24 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, netdev
On Wed, Sep 21, 2011 at 01:57:27PM +0200, Steffen Klassert wrote:
>
> 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.
OK I see what you mean now.
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] xfrm: Perform a replay check after return from async codepaths
2011-09-21 12:24 ` Herbert Xu
@ 2011-09-21 19:21 ` David Miller
0 siblings, 0 replies; 5+ messages in thread
From: David Miller @ 2011-09-21 19:21 UTC (permalink / raw)
To: herbert; +Cc: steffen.klassert, netdev
From: Herbert Xu <herbert@gondor.hengli.com.au>
Date: Wed, 21 Sep 2011 22:24:42 +1000
> On Wed, Sep 21, 2011 at 01:57:27PM +0200, Steffen Klassert wrote:
>>
>> 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.
>
> OK I see what you mean now.
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks everyone.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-09-21 19:21 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-21 9:38 [PATCH] xfrm: Perform a replay check after return from async codepaths Steffen Klassert
2011-09-21 11:21 ` Herbert Xu
2011-09-21 11:57 ` Steffen Klassert
2011-09-21 12:24 ` Herbert Xu
2011-09-21 19:21 ` David Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).