Message ID | 20230126163350.1520752-1-chopps@chopps.org (mailing list archive) |
---|---|
State | Superseded |
Delegated to: | Netdev Maintainers |
Headers | show |
Series | [ipsec-next,v2] xfrm: fix bug with DSCP copy to v6 from v4 tunnel | expand |
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,
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.
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>
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!
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);
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(-)