mbox series

[net,0/4] ipv4: Fix accidental RTO_ONLINK flags passed to ip_route_output_key_hash()

Message ID cover.1641407336.git.gnault@redhat.com (mailing list archive)
Headers show
Series ipv4: Fix accidental RTO_ONLINK flags passed to ip_route_output_key_hash() | expand

Message

Guillaume Nault Jan. 5, 2022, 7:56 p.m. UTC
The IPv4 stack generally uses the last bit of ->flowi4_tos as a flag
indicating link scope for route lookups (RTO_ONLINK). Therefore, we
have to be careful when copying a TOS value to ->flowi4_tos. In
particular, the ->tos field of IPv4 packets may have this bit set
because of ECN. Also tunnel keys generally accept any user value for
the tos.

This series fixes several places where ->flowi4_tos was set from
non-sanitised values and the flowi4 structure was later used by
ip_route_output_key_hash().

Note that the IPv4 stack usually clears the RTO_ONLINK bit using
RT_TOS(). However this macro is based on an obsolete interpretation of
the old IPv4 TOS field (RFC 1349) and clears the three high order bits.
Since we don't need to clear these bits and since it doesn't make sense
to clear only one of the ECN bits, this patch series uses INET_ECN_MASK
instead.

All patches were compile tested only.


Guillaume Nault (4):
  xfrm: Don't accidentally set RTO_ONLINK in decode_session4()
  gre: Don't accidentally set RTO_ONLINK in gre_fill_metadata_dst()
  libcxgb: Don't accidentally set RTO_ONLINK in cxgb_find_route()
  mlx5: Don't accidentally set RTO_ONLINK before
    mlx5e_route_lookup_ipv4_get()

 drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.c   | 3 ++-
 drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c | 5 +++--
 net/ipv4/ip_gre.c                                   | 5 +++--
 net/xfrm/xfrm_policy.c                              | 3 ++-
 4 files changed, 10 insertions(+), 6 deletions(-)

Comments

Jakub Kicinski Jan. 10, 2022, 12:23 a.m. UTC | #1
On Wed, 5 Jan 2022 20:56:16 +0100 Guillaume Nault wrote:
> The IPv4 stack generally uses the last bit of ->flowi4_tos as a flag
> indicating link scope for route lookups (RTO_ONLINK). Therefore, we
> have to be careful when copying a TOS value to ->flowi4_tos. In
> particular, the ->tos field of IPv4 packets may have this bit set
> because of ECN. Also tunnel keys generally accept any user value for
> the tos.
> 
> This series fixes several places where ->flowi4_tos was set from
> non-sanitised values and the flowi4 structure was later used by
> ip_route_output_key_hash().
> 
> Note that the IPv4 stack usually clears the RTO_ONLINK bit using
> RT_TOS(). However this macro is based on an obsolete interpretation of
> the old IPv4 TOS field (RFC 1349) and clears the three high order bits.
> Since we don't need to clear these bits and since it doesn't make sense
> to clear only one of the ECN bits, this patch series uses INET_ECN_MASK
> instead.
> 
> All patches were compile tested only.

Does not apply cleanly to net any more, could you respin?
Guillaume Nault Jan. 10, 2022, 1:59 p.m. UTC | #2
On Sun, Jan 09, 2022 at 04:23:22PM -0800, Jakub Kicinski wrote:
> On Wed, 5 Jan 2022 20:56:16 +0100 Guillaume Nault wrote:
> > The IPv4 stack generally uses the last bit of ->flowi4_tos as a flag
> > indicating link scope for route lookups (RTO_ONLINK). Therefore, we
> > have to be careful when copying a TOS value to ->flowi4_tos. In
> > particular, the ->tos field of IPv4 packets may have this bit set
> > because of ECN. Also tunnel keys generally accept any user value for
> > the tos.
> > 
> > This series fixes several places where ->flowi4_tos was set from
> > non-sanitised values and the flowi4 structure was later used by
> > ip_route_output_key_hash().
> > 
> > Note that the IPv4 stack usually clears the RTO_ONLINK bit using
> > RT_TOS(). However this macro is based on an obsolete interpretation of
> > the old IPv4 TOS field (RFC 1349) and clears the three high order bits.
> > Since we don't need to clear these bits and since it doesn't make sense
> > to clear only one of the ECN bits, this patch series uses INET_ECN_MASK
> > instead.
> > 
> > All patches were compile tested only.
> 
> Does not apply cleanly to net any more, could you respin?

Yes, done:
  https://lore.kernel.org/netdev/cover.1641821242.git.gnault@redhat.com/