All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH net] ipv6: xfrm: Handle errors reported by xfrm6_find_1stfragopt()
@ 2017-05-31 12:15 Ben Hutchings
  2017-05-31 14:01 ` Craig Gallek
  2017-06-02 17:57 ` David Miller
  0 siblings, 2 replies; 3+ messages in thread
From: Ben Hutchings @ 2017-05-31 12:15 UTC (permalink / raw)
  To: Craig Gallek, David S. Miller; +Cc: netdev

[-- Attachment #1: Type: text/plain, Size: 2194 bytes --]

xfrm6_find_1stfragopt() may now return an error code and we must
not treat it as a length.

Fixes: 2423496af35d ("ipv6: Prevent overrun when parsing v6 header options")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
Commits 2423496af35d "ipv6: Prevent overrun when parsing v6 header
options" and 7dd7eb9513bd "ipv6: Check ip6_find_1stfragopt() return
value properly." changed ip6_find_1stfragopt() to return negative
error codes and changed some of its callers to handle this.

However, there is also xfrm6_find_1stfragopt() which is a wrapper for
ip6_find_1stfragopt() and is called indirectly by xfrm6_ro_output()
and xfrm6_transport_output().  Neither of them check for errors.

This is totally untested.  I think xfrm_type::hdr_offset deserves a
comment about its semantics, but I don't understand it well enogugh to
write that.

Ben.

 net/ipv6/xfrm6_mode_ro.c        | 2 ++
 net/ipv6/xfrm6_mode_transport.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/net/ipv6/xfrm6_mode_ro.c b/net/ipv6/xfrm6_mode_ro.c
index 0e015906f9ca..07d36573f50b 100644
--- a/net/ipv6/xfrm6_mode_ro.c
+++ b/net/ipv6/xfrm6_mode_ro.c
@@ -47,6 +47,8 @@ static int xfrm6_ro_output(struct xfrm_state *x, struct sk_buff *skb)
 	iph = ipv6_hdr(skb);
 
 	hdr_len = x->type->hdr_offset(x, skb, &prevhdr);
+	if (hdr_len < 0)
+		return hdr_len;
 	skb_set_mac_header(skb, (prevhdr - x->props.header_len) - skb->data);
 	skb_set_network_header(skb, -x->props.header_len);
 	skb->transport_header = skb->network_header + hdr_len;
diff --git a/net/ipv6/xfrm6_mode_transport.c b/net/ipv6/xfrm6_mode_transport.c
index 7a92c0f31912..9ad07a91708e 100644
--- a/net/ipv6/xfrm6_mode_transport.c
+++ b/net/ipv6/xfrm6_mode_transport.c
@@ -30,6 +30,8 @@ static int xfrm6_transport_output(struct xfrm_state *x, struct sk_buff *skb)
 	skb_set_inner_transport_header(skb, skb_transport_offset(skb));
 
 	hdr_len = x->type->hdr_offset(x, skb, &prevhdr);
+	if (hdr_len < 0)
+		return hdr_len;
 	skb_set_mac_header(skb, (prevhdr - x->props.header_len) - skb->data);
 	skb_set_network_header(skb, -x->props.header_len);
 	skb->transport_header = skb->network_header + hdr_len;

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH net] ipv6: xfrm: Handle errors reported by xfrm6_find_1stfragopt()
  2017-05-31 12:15 [PATCH net] ipv6: xfrm: Handle errors reported by xfrm6_find_1stfragopt() Ben Hutchings
@ 2017-05-31 14:01 ` Craig Gallek
  2017-06-02 17:57 ` David Miller
  1 sibling, 0 replies; 3+ messages in thread
From: Craig Gallek @ 2017-05-31 14:01 UTC (permalink / raw)
  To: Ben Hutchings; +Cc: David S. Miller, netdev

On Wed, May 31, 2017 at 8:15 AM, Ben Hutchings <ben@decadent.org.uk> wrote:
> xfrm6_find_1stfragopt() may now return an error code and we must
> not treat it as a length.
>
> Fixes: 2423496af35d ("ipv6: Prevent overrun when parsing v6 header options")
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> Commits 2423496af35d "ipv6: Prevent overrun when parsing v6 header
> options" and 7dd7eb9513bd "ipv6: Check ip6_find_1stfragopt() return
> value properly." changed ip6_find_1stfragopt() to return negative
> error codes and changed some of its callers to handle this.
>
> However, there is also xfrm6_find_1stfragopt() which is a wrapper for
> ip6_find_1stfragopt() and is called indirectly by xfrm6_ro_output()
> and xfrm6_transport_output().  Neither of them check for errors.
>
> This is totally untested.  I think xfrm_type::hdr_offset deserves a
> comment about its semantics, but I don't understand it well enogugh to
> write that.
Thank you for finding this, it's a good lesson to not rely solely on cscope :\

I believe this fix is correct and sufficient.  I only found 2 up-stack
callers of this (pktgen_output_ipsec and xfrm_output_one) and they
both ultimately call kfree_skb on error.

However, the fact that this function is used as a function pointer
through xfrm_type.hdr_offset made me look at a couple other functions
that can be stored in this structure.  mip6_destopt_offset and
mip6_rthdr_offset have very similar implementations to the original
ip6_find_1stfragopt and may very well suffer from the same bug I was
trying to fix.  Maybe it doesn't matter since that bug relied on the
user changing the v6 nexthdr field.  I need to understand the mip6
code first...

In any event, I think this patch applies on its own.  Thanks again.

Acked-by: Craig Gallek <kraig@google.com>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH net] ipv6: xfrm: Handle errors reported by xfrm6_find_1stfragopt()
  2017-05-31 12:15 [PATCH net] ipv6: xfrm: Handle errors reported by xfrm6_find_1stfragopt() Ben Hutchings
  2017-05-31 14:01 ` Craig Gallek
@ 2017-06-02 17:57 ` David Miller
  1 sibling, 0 replies; 3+ messages in thread
From: David Miller @ 2017-06-02 17:57 UTC (permalink / raw)
  To: ben; +Cc: kraig, netdev

From: Ben Hutchings <ben@decadent.org.uk>
Date: Wed, 31 May 2017 13:15:41 +0100

> xfrm6_find_1stfragopt() may now return an error code and we must
> not treat it as a length.
> 
> Fixes: 2423496af35d ("ipv6: Prevent overrun when parsing v6 header options")
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

Applied and queued up for -stable, thanks Ben.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2017-06-02 17:57 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-31 12:15 [PATCH net] ipv6: xfrm: Handle errors reported by xfrm6_find_1stfragopt() Ben Hutchings
2017-05-31 14:01 ` Craig Gallek
2017-06-02 17:57 ` David Miller

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.