Re: [PATCH net] openvswitch: Fix skb leak in IPv6 reassembly.
From: Florian Westphal <fw@strlen.de>
Date: 2016-11-29 00:48:01
Eric Dumazet [off-list ref] wrote:
On Mon, 2016-11-28 at 15:43 -0800, Daniele Di Proietto wrote:quoted
If nf_ct_frag6_gather() returns an error other than -EINPROGRESS, it means that we still have a reference to the skb. We should free it before returning from handle_fragments, as stated in the comment above. Fixes: daaa7d647f81 ("netfilter: ipv6: avoid nf_iterate recursion") CC: Florian Westphal <fw@strlen.de> CC: Pravin B Shelar <redacted> CC: Joe Stringer <redacted> Signed-off-by: Daniele Di Proietto <redacted> --- net/openvswitch/conntrack.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c index 31045ef..fecefa2 100644 --- a/net/openvswitch/conntrack.c +++ b/net/openvswitch/conntrack.c@@ -370,8 +370,11 @@ static int handle_fragments(struct net *net, struct sw_flow_key *key, skb_orphan(skb); memset(IP6CB(skb), 0, sizeof(struct inet6_skb_parm)); err = nf_ct_frag6_gather(net, skb, user); - if (err) + if (err) { + if (err != -EINPROGRESS) + kfree_skb(skb); return err; + } key->ip.proto = ipv6_hdr(skb)->nexthdr; ovs_cb.mru = IP6CB(skb)->frag_max_size;Interesting, have you followed the "GPF in eth_header" thread today ? In a nutshell, we want a complete patch, not something that would solve part of the problem.
I think this patch is fine, intent seems to be to only take fully reassembled skb, rather than a stray fragment (ovs does NOT seem to call handle_fragments in case skb is already known to not contain a fragment header, afaics). I'll send a patch for the GPF in eth_header thing soon.