From: Fan Du <fan.du@windriver.com>
To: Steffen Klassert <steffen.klassert@secunet.com>
Cc: <davem@davemloft.net>, <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next 2/3] xfrm: clamp down spi range for IPComp when allocating spi
Date: Mon, 9 Dec 2013 14:27:43 +0800 [thread overview]
Message-ID: <52A562DF.4090302@windriver.com> (raw)
In-Reply-To: <20131206114248.GG31491@secunet.com>
On 2013年12月06日 19:42, Steffen Klassert wrote:
> On Thu, Nov 28, 2013 at 10:52:40AM +0800, Fan Du wrote:
>> otherwise xfrm state can not be found properly by peers.
>>
>> Signed-off-by: Fan Du<fan.du@windriver.com>
>> ---
>> net/xfrm/xfrm_state.c | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
>> index 68c2f35..a6716d7 100644
>> --- a/net/xfrm/xfrm_state.c
>> +++ b/net/xfrm/xfrm_state.c
>> @@ -1506,6 +1506,19 @@ int xfrm_alloc_spi(struct xfrm_state *x, u32 low, u32 high)
>> __be32 maxspi = htonl(high);
>> u32 mark = x->mark.v& x->mark.m;
>>
>> + /* Compression Parameter Index(CPI) is 16bits wide
>> + * An 32 bits spi value will hash xfrm_state into wrong hash slot.
>> + * When the upper 16bits of spi values is used as CPI for the peer
>> + * to look up xfrm state, it would generate XfrmOutNoStates error,
>> + * as apparently we are looking for the wrong hash slot.
>> + *
>> + * So clamp down the spi range into only 16bits valid wide.
>> + */
>> + if (x->id.proto == IPPROTO_COMP) {
>> + minspi = htonl(0xc00);
>> + maxspi = htonl(0xff00);
>> + }
>
> This does not make sense. The spi is chosen based on minspi only
> if minspi is equal to maxspi. This will be never the case for
> IPPROTO_COMP with your patch.
>
> Also, the spi range is user defined, we should respect the
> users configuration if the range is valid.
Ok, then, speaking of respect user defined range, how about below informal
patch which only check the validity of the range? My original thoughts is CPI
is only 16bits wide, kernel itself can keep the CPI's validity. btw, v2 will
also fix patch1/3 align issue.
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 6a9c402..2c6fb99 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1507,6 +1507,9 @@ int xfrm_alloc_spi(struct xfrm_state *x, u32 low, u32 high)
err = -ENOENT;
+ if ((x->id.proto == IPPROTO_COMP) && (high > 0xFFFF))
+ goto unlock;
+
if (minspi == maxspi) {
x0 = xfrm_state_lookup(net, mark, &x->id.daddr, minspi, x->id.proto, x->props.family);
if (x0) {
--
浮沉随浪只记今朝笑
--fan
next prev parent reply other threads:[~2013-12-09 6:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-28 2:52 [PATCH net-next 0/3] IPComp fixes Fan Du
2013-11-28 2:52 ` [PATCH net-next 1/3] xfrm: check user specified spi for IPComp Fan Du
2013-12-06 11:44 ` Steffen Klassert
2013-11-28 2:52 ` [PATCH net-next 2/3] xfrm: clamp down spi range for IPComp when allocating spi Fan Du
2013-12-06 11:42 ` Steffen Klassert
2013-12-09 6:27 ` Fan Du [this message]
2013-12-09 8:57 ` Steffen Klassert
2013-12-09 9:13 ` Fan Du
2013-12-09 9:51 ` Steffen Klassert
2013-12-09 9:58 ` Fan Du
2013-11-28 2:52 ` [PATCH net-next 3/3] xfrm: Restrict "level use" for IPComp configuration Fan Du
2013-12-09 10:38 ` Steffen Klassert
2013-12-10 2:39 ` Fan Du
2013-12-10 13:11 ` Steffen Klassert
2013-12-13 9:16 ` Fan Du
2013-12-06 9:58 ` [PATCH net-next 0/3] IPComp fixes Fan Du
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52A562DF.4090302@windriver.com \
--to=fan.du@windriver.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).