xfrm: Perform a replay check after return from async codepaths
Subsystems (3)
Steffen Klassert
maintainerPATCH 1/1 xfrm: Perform a replay check after return from async codepaths
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.
--- net/xfrm/xfrm_input.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
net/xfrm/xfrm_input.c +5 -0
@@ -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;
Signature · 1 line
1.7.0.4
Herbert Xu
maintainerQuoted 8 lines · Steffen Klassert
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.
Quoted 4 lines
This pach adds a second replay check after resuming from the async processing to fix these issues.
Signed-off-by Steffen Klassert <[email protected]>
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,
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Steffen Klassert
maintainerQuoted 9 lines · Herbert Xu
Quoted 8 lines · Steffen Klassert
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.
Quoted 9 lines
Quoted 4 lines
This pach adds a second replay check after resuming from the async processing to fix these issues.
Signed-off-by Steffen Klassert <[email protected]>Actually why does this matter? For a single SA, the processing in
xfrm_inputshould 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.
Quoted 4 lines · Steffen Klassert
Well, I've got pretty reproduceable crashes when the sender of the IPsec packets introduces reorder, that's why I noticed this.
Quoted 9 lines
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.
Thanks!
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
From: Herbert Xu <[email protected]>
Date: Wed, 21 Sep 2011 22:24:42 +1000
Quoted 15 lines · Steffen Klassert
Quoted 4 lines
Well, I've got pretty reproduceable crashes when the sender of the IPsec packets introduces reorder, that's why I noticed this.
Quoted 9 lines
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.
Quoted 3 lines
OK I see what you mean now.
Acked-by Herbert Xu <[email protected]>
Applied, thanks everyone.