From: Steffen Klassert <steffen.klassert@secunet•com>
To: David Miller <davem@davemloft•net>
Cc: Herbert Xu <herbert@gondor•apana.org.au>,
Steffen Klassert <steffen.klassert@secunet•com>,
<netdev@vger•kernel.org>
Subject: [PATCH 01/11] xfrm: Forbid state updates from changing encap type
Date: Thu, 11 Jan 2018 12:37:36 +0100 [thread overview]
Message-ID: <20180111113746.28186-2-steffen.klassert@secunet.com> (raw)
In-Reply-To: <20180111113746.28186-1-steffen.klassert@secunet.com>
From: Herbert Xu <herbert@gondor•apana.org.au>
Currently we allow state updates to competely replace the contents
of x->encap. This is bad because on the user side ESP only sets up
header lengths depending on encap_type once when the state is first
created. This could result in the header lengths getting out of
sync with the actual state configuration.
In practice key managers will never do a state update to change the
encapsulation type. Only the port numbers need to be changed as the
peer NAT entry is updated.
Therefore this patch adds a check in xfrm_state_update to forbid
any changes to the encap_type.
Signed-off-by: Herbert Xu <herbert@gondor•apana.org.au>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet•com>
---
net/xfrm/xfrm_state.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 500b3391f474..1e80f68e2266 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1534,8 +1534,12 @@ int xfrm_state_update(struct xfrm_state *x)
err = -EINVAL;
spin_lock_bh(&x1->lock);
if (likely(x1->km.state == XFRM_STATE_VALID)) {
- if (x->encap && x1->encap)
+ if (x->encap && x1->encap &&
+ x->encap->encap_type == x1->encap->encap_type)
memcpy(x1->encap, x->encap, sizeof(*x1->encap));
+ else if (x->encap || x1->encap)
+ goto fail;
+
if (x->coaddr && x1->coaddr) {
memcpy(x1->coaddr, x->coaddr, sizeof(*x1->coaddr));
}
@@ -1552,6 +1556,8 @@ int xfrm_state_update(struct xfrm_state *x)
x->km.state = XFRM_STATE_DEAD;
__xfrm_state_put(x);
}
+
+fail:
spin_unlock_bh(&x1->lock);
xfrm_state_put(x1);
--
2.14.1
next prev parent reply other threads:[~2018-01-11 11:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-11 11:37 pull request (net): ipsec 2018-01-11 Steffen Klassert
2018-01-11 11:37 ` Steffen Klassert [this message]
2018-01-11 11:37 ` [PATCH 02/11] xfrm: skip policies marked as dead while rehashing Steffen Klassert
2018-01-11 11:37 ` [PATCH 03/11] af_key: fix buffer overread in verify_address_len() Steffen Klassert
2018-01-11 11:37 ` [PATCH 04/11] af_key: fix buffer overread in parse_exthdrs() Steffen Klassert
2018-01-11 11:37 ` [PATCH 05/11] xfrm: fix rcu usage in xfrm_get_type_offload Steffen Klassert
2018-01-11 11:37 ` [PATCH 06/11] xfrm: Use __skb_queue_tail in xfrm_trans_queue Steffen Klassert
2018-01-11 11:37 ` [PATCH 07/11] xfrm: Return error on unknown encap_type in init_state Steffen Klassert
2018-01-11 11:37 ` [PATCH 08/11] xfrm: don't call xfrm_policy_cache_flush while holding spinlock Steffen Klassert
2018-01-11 11:37 ` [PATCH 09/11] esp: Fix GRO when the headers not fully in the linear part of the skb Steffen Klassert
2018-01-11 11:37 ` [PATCH 10/11] af_key: Fix memory leak in key_notify_policy Steffen Klassert
2018-01-11 11:37 ` [PATCH 11/11] xfrm: Fix a race in the xdst pcpu cache Steffen Klassert
2018-01-12 15:33 ` pull request (net): ipsec 2018-01-11 David Miller
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=20180111113746.28186-2-steffen.klassert@secunet.com \
--to=steffen.klassert@secunet$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=herbert@gondor$(echo .)apana.org.au \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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