lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon,  3 Aug 2020 22:52:09 +0200
From:   Stefano Brivio <sbrivio@...hat.com>
To:     "David S. Miller" <davem@...emloft.net>
Cc:     Florian Westphal <fw@...len.de>, David Ahern <dsahern@...il.com>,
        Aaron Conole <aconole@...hat.com>,
        Numan Siddique <nusiddiq@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Pravin B Shelar <pshelar@....org>,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
        Lourdes Pedrajas <lu@...o.net>, netdev@...r.kernel.org
Subject: [PATCH net-next 1/6] ipv4: route: Ignore output interface in FIB lookup for PMTU route

Currently, processes sending traffic to a local bridge with an
encapsulation device as a port don't get ICMP errors if they exceed
the PMTU of the encapsulated link.

David Ahern suggested this as a hack, but it actually looks like
the correct solution: when we update the PMTU for a given destination
by means of updating or creating a route exception, the encapsulation
might trigger this because of PMTU discovery happening either on the
encapsulation device itself, or its lower layer.

The output interface shouldn't matter, because we already have a
valid destination. Drop the output interface restriction from the
associated route lookup.

For UDP tunnels, we will now have a route exception created for the
encapsulation itself, with a MTU value reflecting its headroom, which
allows a bridge forwarding IP packets originated locally to deliver
errors back to the sending socket.

The behaviour is now consistent with IPv6 and verified with selftests
pmtu_ipv{4,6}_br_{geneve,vxlan}{4,6}_exception introduced later in
this series.

Suggested-by: David Ahern <dsahern@...il.com>
Signed-off-by: Stefano Brivio <sbrivio@...hat.com>
---
 net/ipv4/route.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index a01efa062f6b..c14fd8124f57 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1050,6 +1050,7 @@ static void ip_rt_update_pmtu(struct dst_entry *dst, struct sock *sk,
 	struct flowi4 fl4;
 
 	ip_rt_build_flow_key(&fl4, sk, skb);
+	fl4.flowi4_oif = 0;	/* Don't make lookup fail for encapsulations */
 	__ip_rt_update_pmtu(rt, &fl4, mtu);
 }
 
-- 
2.27.0

Powered by blists - more mailing lists