[PATCH net 1/2] openvswitch: Properly set L4 keys on "later" IP fragments.

[PATCH net 1/2] openvswitch: Properly set L4 keys on "later" IP fragments.

[Justin Pettit]

When IP fragments are reassembled before being sent to conntrack, the
key from the last fragment is used.  Unless there are reordering
issues, the last fragment received will not contain the L4 ports, so the
key for the reassembled datagram won't contain them.  This patch updates
the key once we have a reassembled datagram.

Signed-off-by: Justin Pettit <jpettit@ovn.org>
---
 net/openvswitch/conntrack.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 848c6eb55064..f40ad2a42086 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -524,6 +524,10 @@ static int handle_fragments(struct net *net, struct sw_flow_key *key,
 		return -EPFNOSUPPORT;
 	}
 
+	/* The key extracted from the fragment that completed this datagram
+	 * likely didn't have an L4 header, so regenerate it. */
+	ovs_flow_key_update(skb, key);
+
 	key->ip.frag = OVS_FRAG_TYPE_NONE;
 	skb_clear_hash(skb);
 	skb->ignore_df = 1;
-- 
2.17.1

[PATCH net 2/2] openvswitch: Clear the L4 portion of the key for "later" fragments.

[Justin Pettit]

Only the first fragment in a datagram contains the L4 headers.  When the
Open vSwitch module parses a packet, it always sets the IP protocol
field in the key, but can only set the L4 fields on the first fragment.
The original behavior would not clear the L4 portion of the key, so
garbage values would be sent in the key for "later" fragments.  This
patch clears the L4 fields in that circumstance to prevent sending those
garbage values as part of the upcall.

Signed-off-by: Justin Pettit <jpettit@ovn.org>
---
 net/openvswitch/flow.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index bc89e16e0505..0fb2cec08523 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -623,6 +623,7 @@ static int key_extract(struct sk_buff *skb, struct sw_flow_key *key)
 		offset = nh->frag_off & htons(IP_OFFSET);
 		if (offset) {
 			key->ip.frag = OVS_FRAG_TYPE_LATER;
+			memset(&key->tp, 0, sizeof(key->tp));
 			return 0;
 		}
 		if (nh->frag_off & htons(IP_MF) ||
@@ -740,8 +741,10 @@ static int key_extract(struct sk_buff *skb, struct sw_flow_key *key)
 			return error;
 		}
 
-		if (key->ip.frag == OVS_FRAG_TYPE_LATER)
+		if (key->ip.frag == OVS_FRAG_TYPE_LATER) {
+			memset(&key->tp, 0, sizeof(key->tp));
 			return 0;
+		}
 		if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP)
 			key->ip.frag = OVS_FRAG_TYPE_FIRST;
 
-- 
2.17.1

Re: [PATCH net 2/2] openvswitch: Clear the L4 portion of the key for "later" fragments.

[Pravin Shelar]

On Sat, Aug 24, 2019 at 9:58 AM Justin Pettit <jpettit@ovn.org> wrote:
>
> Only the first fragment in a datagram contains the L4 headers.  When the
> Open vSwitch module parses a packet, it always sets the IP protocol
> field in the key, but can only set the L4 fields on the first fragment.
> The original behavior would not clear the L4 portion of the key, so
> garbage values would be sent in the key for "later" fragments.  This
> patch clears the L4 fields in that circumstance to prevent sending those
> garbage values as part of the upcall.
>
> Signed-off-by: Justin Pettit <jpettit@ovn.org>
> ---
>  net/openvswitch/flow.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
> index bc89e16e0505..0fb2cec08523 100644
> --- a/net/openvswitch/flow.c
> +++ b/net/openvswitch/flow.c
> @@ -623,6 +623,7 @@ static int key_extract(struct sk_buff *skb, struct sw_flow_key *key)
>                 offset = nh->frag_off & htons(IP_OFFSET);
>                 if (offset) {
>                         key->ip.frag = OVS_FRAG_TYPE_LATER;
> +                       memset(&key->tp, 0, sizeof(key->tp));
>                         return 0;
>                 }
>                 if (nh->frag_off & htons(IP_MF) ||
> @@ -740,8 +741,10 @@ static int key_extract(struct sk_buff *skb, struct sw_flow_key *key)
>                         return error;
>                 }
>
> -               if (key->ip.frag == OVS_FRAG_TYPE_LATER)
> +               if (key->ip.frag == OVS_FRAG_TYPE_LATER) {
> +                       memset(&key->tp, 0, sizeof(key->tp));
>                         return 0;
> +               }
>                 if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP)
>                         key->ip.frag = OVS_FRAG_TYPE_FIRST;
>

Looks good to me.

Acked-by: Pravin B Shelar <pshelar@ovn.org>

Thanks,
Pravin.

Re: [PATCH net 1/2] openvswitch: Properly set L4 keys on "later" IP fragments.

[Pravin Shelar]

On Sat, Aug 24, 2019 at 9:58 AM Justin Pettit <jpettit@ovn.org> wrote:
>
> When IP fragments are reassembled before being sent to conntrack, the
> key from the last fragment is used.  Unless there are reordering
> issues, the last fragment received will not contain the L4 ports, so the
> key for the reassembled datagram won't contain them.  This patch updates
> the key once we have a reassembled datagram.
>
> Signed-off-by: Justin Pettit <jpettit@ovn.org>
> ---
>  net/openvswitch/conntrack.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
> index 848c6eb55064..f40ad2a42086 100644
> --- a/net/openvswitch/conntrack.c
> +++ b/net/openvswitch/conntrack.c
> @@ -524,6 +524,10 @@ static int handle_fragments(struct net *net, struct sw_flow_key *key,
>                 return -EPFNOSUPPORT;
>         }
>
> +       /* The key extracted from the fragment that completed this datagram
> +        * likely didn't have an L4 header, so regenerate it. */
> +       ovs_flow_key_update(skb, key);
> +
>         key->ip.frag = OVS_FRAG_TYPE_NONE;
>         skb_clear_hash(skb);
>         skb->ignore_df = 1;
> --

Looks good to me.

Acked-by: Pravin B Shelar <pshelar@ovn.org>

Thanks,
Pravin.

Re: [PATCH net 1/2] openvswitch: Properly set L4 keys on "later" IP fragments.

[Pravin Shelar]

On Sun, Aug 25, 2019 at 9:54 AM Pravin Shelar <pshelar@ovn.org> wrote:
>
> On Sat, Aug 24, 2019 at 9:58 AM Justin Pettit <jpettit@ovn.org> wrote:
> >
> > When IP fragments are reassembled before being sent to conntrack, the
> > key from the last fragment is used.  Unless there are reordering
> > issues, the last fragment received will not contain the L4 ports, so the
> > key for the reassembled datagram won't contain them.  This patch updates
> > the key once we have a reassembled datagram.
> >
> > Signed-off-by: Justin Pettit <jpettit@ovn.org>
> > ---
> >  net/openvswitch/conntrack.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
> > index 848c6eb55064..f40ad2a42086 100644
> > --- a/net/openvswitch/conntrack.c
> > +++ b/net/openvswitch/conntrack.c
> > @@ -524,6 +524,10 @@ static int handle_fragments(struct net *net, struct sw_flow_key *key,
> >                 return -EPFNOSUPPORT;
> >         }
> >
> > +       /* The key extracted from the fragment that completed this datagram
> > +        * likely didn't have an L4 header, so regenerate it. */
> > +       ovs_flow_key_update(skb, key);
> > +
> >         key->ip.frag = OVS_FRAG_TYPE_NONE;
> >         skb_clear_hash(skb);
> >         skb->ignore_df = 1;
> > --
>
> Looks good to me.
>
> Acked-by: Pravin B Shelar <pshelar@ovn.org>
>
Actually I am not sure about this change. caller of this function
(ovs_ct_execute()) does skb-pull and push of L2 header, calling
ovs_flow_key_update() is not safe here, it expect skb data to point to
L2 header.

Re: [PATCH net 1/2] openvswitch: Properly set L4 keys on "later" IP fragments.

[David Miller]

From: Pravin Shelar <pshelar@ovn.org>
Date: Sun, 25 Aug 2019 13:40:58 -0700

> On Sun, Aug 25, 2019 at 9:54 AM Pravin Shelar <pshelar@ovn.org> wrote:
>>
>> On Sat, Aug 24, 2019 at 9:58 AM Justin Pettit <jpettit@ovn.org> wrote:
>> >
>> > When IP fragments are reassembled before being sent to conntrack, the
>> > key from the last fragment is used.  Unless there are reordering
>> > issues, the last fragment received will not contain the L4 ports, so the
>> > key for the reassembled datagram won't contain them.  This patch updates
>> > the key once we have a reassembled datagram.
>> >
>> > Signed-off-by: Justin Pettit <jpettit@ovn.org>
>> > ---
>> >  net/openvswitch/conntrack.c | 4 ++++
>> >  1 file changed, 4 insertions(+)
>> >
>> > diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
>> > index 848c6eb55064..f40ad2a42086 100644
>> > --- a/net/openvswitch/conntrack.c
>> > +++ b/net/openvswitch/conntrack.c
>> > @@ -524,6 +524,10 @@ static int handle_fragments(struct net *net, struct sw_flow_key *key,
>> >                 return -EPFNOSUPPORT;
>> >         }
>> >
>> > +       /* The key extracted from the fragment that completed this datagram
>> > +        * likely didn't have an L4 header, so regenerate it. */
>> > +       ovs_flow_key_update(skb, key);
>> > +
>> >         key->ip.frag = OVS_FRAG_TYPE_NONE;
>> >         skb_clear_hash(skb);
>> >         skb->ignore_df = 1;
>> > --
>>
>> Looks good to me.
>>
>> Acked-by: Pravin B Shelar <pshelar@ovn.org>
>>
> Actually I am not sure about this change. caller of this function
> (ovs_ct_execute()) does skb-pull and push of L2 header, calling
> ovs_flow_key_update() is not safe here, it expect skb data to point to
> L2 header.

Agreed, also the comment needs to be formatted properly ala:

	/* blah
	 * blah
	 */

instead of:

	/* blah
	 * blah */

Re: [PATCH net 1/2] openvswitch: Properly set L4 keys on "later" IP fragments.

[Justin Pettit]

> On Aug 25, 2019, at 1:40 PM, Pravin Shelar <pshelar@ovn.org> wrote:
> 
> Actually I am not sure about this change. caller of this function
> (ovs_ct_execute()) does skb-pull and push of L2 header, calling
> ovs_flow_key_update() is not safe here, it expect skb data to point to
> L2 header.

Thanks for the feedback, Pravin and David.  Greg Rose has a revised version that will address the issues you raised and also make it so that we don't bother re-extracting the L2 headers.  He'll hopefully get that out today once we've done some internal testing on it.

--Justin