[PATCH] xfrm: fix bug with DSCP copy to v6 from v4 tunnel

[PATCH] xfrm: fix bug with DSCP copy to v6 from v4 tunnel

[Christian Hopps]

When copying the DSCP bits for decap-dscp into IPv6 don't assume the
outer encap is always IPv6. Instead, as with the inner IPv4 case, copy
the DSCP bits from the correctly saved "tos" value in the control block.

fixes: 227620e29509 ("[IPSEC]: Separate inner/outer mode processing on input")

Signed-off-by: Christian Hopps <chopps@labn.net>
---
 net/xfrm/xfrm_input.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index c06e54a10540..436d29640ac2 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -279,8 +279,7 @@ static int xfrm6_remove_tunnel_encap(struct xfrm_state *x, struct sk_buff *skb)
 		goto out;
 
 	if (x->props.flags & XFRM_STATE_DECAP_DSCP)
-		ipv6_copy_dscp(ipv6_get_dsfield(ipv6_hdr(skb)),
-			       ipipv6_hdr(skb));
+		ipv6_copy_dscp(XFRM_MODE_SKB_CB(skb)->tos, ipipv6_hdr(skb));
 	if (!(x->props.flags & XFRM_STATE_NOECN))
 		ipip6_ecn_decapsulate(skb);
 
-- 
2.34.1

[PATCH ipsec-next v2] xfrm: fix bug with DSCP copy to v6 from v4 tunnel

[Christian Hopps]

When copying the DSCP bits for decap-dscp into IPv6 don't assume the
outer encap is always IPv6. Instead, as with the inner IPv4 case, copy
the DSCP bits from the correctly saved "tos" value in the control block.

Fixes: 227620e29509 ("[IPSEC]: Separate inner/outer mode processing on input")

Signed-off-by: Christian Hopps <chopps@chopps.org>
---
 net/xfrm/xfrm_input.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index c06e54a10540..436d29640ac2 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -279,8 +279,7 @@ static int xfrm6_remove_tunnel_encap(struct xfrm_state *x, struct sk_buff *skb)
 		goto out;
 
 	if (x->props.flags & XFRM_STATE_DECAP_DSCP)
-		ipv6_copy_dscp(ipv6_get_dsfield(ipv6_hdr(skb)),
-			       ipipv6_hdr(skb));
+		ipv6_copy_dscp(XFRM_MODE_SKB_CB(skb)->tos, ipipv6_hdr(skb));
 	if (!(x->props.flags & XFRM_STATE_NOECN))
 		ipip6_ecn_decapsulate(skb);
 
-- 
2.34.1

Re: [PATCH] xfrm: fix bug with DSCP copy to v6 from v4 tunnel

[Herbert Xu]

On Thu, Jan 26, 2023 at 05:29:34AM -0500, Christian Hopps wrote:
> When copying the DSCP bits for decap-dscp into IPv6 don't assume the
> outer encap is always IPv6. Instead, as with the inner IPv4 case, copy
> the DSCP bits from the correctly saved "tos" value in the control block.
> 
> fixes: 227620e29509 ("[IPSEC]: Separate inner/outer mode processing on input")

The broken code apparently came from

commit b3284df1c86f7ac078dcb8fb250fe3d6437e740c
Author: Florian Westphal <fw@strlen.de>
Date:   Fri Mar 29 21:16:28 2019 +0100

    xfrm: remove input2 indirection from xfrm_mode

Please fix the Fixes header.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH ipsec-next v2] xfrm: fix bug with DSCP copy to v6 from v4 tunnel

[Herbert Xu]

On Thu, Jan 26, 2023 at 11:33:50AM -0500, Christian Hopps wrote:
> When copying the DSCP bits for decap-dscp into IPv6 don't assume the
> outer encap is always IPv6. Instead, as with the inner IPv4 case, copy
> the DSCP bits from the correctly saved "tos" value in the control block.
> 
> Fixes: 227620e29509 ("[IPSEC]: Separate inner/outer mode processing on input")

Please fix this Fixes header as that commit did not introduce
this bug.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH ipsec-next v2] xfrm: fix bug with DSCP copy to v6 from v4 tunnel

[Christian Hopps]

Herbert Xu <herbert@gondor.apana.org.au> writes:

> On Thu, Jan 26, 2023 at 11:33:50AM -0500, Christian Hopps wrote:
>> When copying the DSCP bits for decap-dscp into IPv6 don't assume the
>> outer encap is always IPv6. Instead, as with the inner IPv4 case, copy
>> the DSCP bits from the correctly saved "tos" value in the control block.
>>
>> Fixes: 227620e29509 ("[IPSEC]: Separate inner/outer mode processing on input")
>
> Please fix this Fixes header as that commit did not introduce
> this bug.

This was a suggested add from Eyal that I was initially hesitant to add. He justified it b/c this commit purported to add support for mixed versions and this is a bug in that new functionality. It is useful to have that tracked which is why I added it. Is there a better way to track that?

Thanks,
Chris.

Re: [PATCH] xfrm: fix bug with DSCP copy to v6 from v4 tunnel

[Christian Hopps]

Herbert Xu <herbert@gondor.apana.org.au> writes:

> On Thu, Jan 26, 2023 at 05:29:34AM -0500, Christian Hopps wrote:
>> When copying the DSCP bits for decap-dscp into IPv6 don't assume the
>> outer encap is always IPv6. Instead, as with the inner IPv4 case, copy
>> the DSCP bits from the correctly saved "tos" value in the control block.
>>
>> fixes: 227620e29509 ("[IPSEC]: Separate inner/outer mode processing on input")
>
> The broken code apparently came from
>
> commit b3284df1c86f7ac078dcb8fb250fe3d6437e740c
> Author: Florian Westphal <fw@strlen.de>
> Date:   Fri Mar 29 21:16:28 2019 +0100
>
>     xfrm: remove input2 indirection from xfrm_mode
>
> Please fix the Fixes header.

Yes that's what the immediate git blame points at; however, that code was copied from net/ipv6/xfrm6_mode_tunnel.c:xfrm6_tunnel_input() and that code arrived in:

    b59f45d0b2878 ("[IPSEC] xfrm: Abstract out encapsulation modes")

Originally this code using a different sk_buff layout was from the initial git repo checkin.

    1da177e4c3f41 ("Linux-2.6.12-rc2")

Why don't I just remove the fixes line? I didn't want to include it initially anyway.

Thanks,
Chris.

>
> Thanks,

[PATCH ipsec-next v3] xfrm: fix bug with DSCP copy to v6 from v4 tunnel

[Christian Hopps]

When copying the DSCP bits for decap-dscp into IPv6 don't assume the
outer encap is always IPv6. Instead, as with the inner IPv4 case, copy
the DSCP bits from the correctly saved "tos" value in the control block.

Signed-off-by: Christian Hopps <chopps@labn.net>
---
 net/xfrm/xfrm_input.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index c06e54a10540..436d29640ac2 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -279,8 +279,7 @@ static int xfrm6_remove_tunnel_encap(struct xfrm_state *x, struct sk_buff *skb)
 		goto out;
 
 	if (x->props.flags & XFRM_STATE_DECAP_DSCP)
-		ipv6_copy_dscp(ipv6_get_dsfield(ipv6_hdr(skb)),
-			       ipipv6_hdr(skb));
+		ipv6_copy_dscp(XFRM_MODE_SKB_CB(skb)->tos, ipipv6_hdr(skb));
 	if (!(x->props.flags & XFRM_STATE_NOECN))
 		ipip6_ecn_decapsulate(skb);
 
-- 
2.34.1

Re: [PATCH ipsec-next v3] xfrm: fix bug with DSCP copy to v6 from v4 tunnel

[Herbert Xu]

On Fri, Jan 27, 2023 at 05:58:20PM -0500, Christian Hopps wrote:
> When copying the DSCP bits for decap-dscp into IPv6 don't assume the
> outer encap is always IPv6. Instead, as with the inner IPv4 case, copy
> the DSCP bits from the correctly saved "tos" value in the control block.
> 
> Signed-off-by: Christian Hopps <chopps@labn.net>
> ---
>  net/xfrm/xfrm_input.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Acked-by: Herbert Xu <herbert@gondor.apana.org.au>

Thanks!
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] xfrm: fix bug with DSCP copy to v6 from v4 tunnel

[Herbert Xu]

On Fri, Jan 27, 2023 at 07:31:54AM -0500, Christian Hopps wrote:
>
> Yes that's what the immediate git blame points at; however, that code was copied from net/ipv6/xfrm6_mode_tunnel.c:xfrm6_tunnel_input() and that code arrived in:
> 
>    b59f45d0b2878 ("[IPSEC] xfrm: Abstract out encapsulation modes")
> 
> Originally this code using a different sk_buff layout was from the initial git repo checkin.
> 
>    1da177e4c3f41 ("Linux-2.6.12-rc2")
> 
> Why don't I just remove the fixes line? I didn't want to include it initially anyway.

On closer inspection my patch was definitely buggy in that it would
place some random value in the DSCP field.  Previously the code
simply didn't copy the TOS value across.

Steffen, keeping the Fixes header is fine by me.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH ipsec-next v2] xfrm: fix bug with DSCP copy to v6 from v4 tunnel

[Herbert Xu]

On Thu, Jan 26, 2023 at 11:33:50AM -0500, Christian Hopps wrote:
> When copying the DSCP bits for decap-dscp into IPv6 don't assume the
> outer encap is always IPv6. Instead, as with the inner IPv4 case, copy
> the DSCP bits from the correctly saved "tos" value in the control block.
> 
> Fixes: 227620e29509 ("[IPSEC]: Separate inner/outer mode processing on input")
> 
> Signed-off-by: Christian Hopps <chopps@chopps.org>
> ---
>  net/xfrm/xfrm_input.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH ipsec-next v2] xfrm: fix bug with DSCP copy to v6 from v4 tunnel

[Steffen Klassert]

On Sat, Jan 28, 2023 at 09:42:26AM +0800, Herbert Xu wrote:
> On Thu, Jan 26, 2023 at 11:33:50AM -0500, Christian Hopps wrote:
> > When copying the DSCP bits for decap-dscp into IPv6 don't assume the
> > outer encap is always IPv6. Instead, as with the inner IPv4 case, copy
> > the DSCP bits from the correctly saved "tos" value in the control block.
> > 
> > Fixes: 227620e29509 ("[IPSEC]: Separate inner/outer mode processing on input")
> > 
> > Signed-off-by: Christian Hopps <chopps@chopps.org>
> > ---
> >  net/xfrm/xfrm_input.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>

I've applied the version with the 'Fixes' tag to the
ipsec tree, thanks everyone!