]> www.infradead.org Git - users/dwmw2/linux.git/commit
ipv4: Fix incorrect TOS in route get reply
authorIdo Schimmel <idosch@nvidia.com>
Mon, 15 Jul 2024 14:23:53 +0000 (17:23 +0300)
committerPaolo Abeni <pabeni@redhat.com>
Thu, 18 Jul 2024 09:11:02 +0000 (11:11 +0200)
commit338bb57e4c2a1c2c6fc92f9c0bd35be7587adca7
tree0ed0eb58ce8cee240c90bc302a00be4d74b213df
parent120f1c857a73e52132e473dee89b340440cb692b
ipv4: Fix incorrect TOS in route get reply

The TOS value that is returned to user space in the route get reply is
the one with which the lookup was performed ('fl4->flowi4_tos'). This is
fine when the matched route is configured with a TOS as it would not
match if its TOS value did not match the one with which the lookup was
performed.

However, matching on TOS is only performed when the route's TOS is not
zero. It is therefore possible to have the kernel incorrectly return a
non-zero TOS:

 # ip link add name dummy1 up type dummy
 # ip address add 192.0.2.1/24 dev dummy1
 # ip route get 192.0.2.2 tos 0xfc
 192.0.2.2 tos 0x1c dev dummy1 src 192.0.2.1 uid 0
     cache

Fix by adding a DSCP field to the FIB result structure (inside an
existing 4 bytes hole), populating it in the route lookup and using it
when filling the route get reply.

Output after the patch:

 # ip link add name dummy1 up type dummy
 # ip address add 192.0.2.1/24 dev dummy1
 # ip route get 192.0.2.2 tos 0xfc
 192.0.2.2 dev dummy1 src 192.0.2.1 uid 0
     cache

Fixes: 1a00fee4ffb2 ("ipv4: Remove rt_key_{src,dst,tos} from struct rtable.")
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Reviewed-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
include/net/ip_fib.h
net/ipv4/fib_trie.c
net/ipv4/route.c