netdev - Re: [PATCH] IPv6: fix rt_lookup in pmtu

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b91784ff1001081612g7c15e968u5e77931289af25c@mail.gmail.com>
Date:	Fri, 8 Jan 2010 16:12:55 -0800
From:	Lorenzo Colitti <lorenzo@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	zenczykowski@...il.com, therbert@...gle.com, netdev@...r.kernel.org
Subject: Re: [PATCH] IPv6: fix rt_lookup in pmtu_discovery

2010/1/7 David Miller <davem@...emloft.net>
>    ipv4: Update MTU to all related cache entries in ip_rt_frag_needed()
>
>    Add struct net_device parameter to ip_rt_frag_needed() and update MTU to
>    cache entries where ifindex is specified. This is similar to what is
>    already done in ip_rt_redirect().
> [...]
> +       int  ikeys[2] = { dev->ifindex, 0 };
>        __be32  skeys[2] = { iph->saddr, 0, };
>        __be32  daddr = iph->daddr;
> [...]

That patch makes it so that if a fragmentation needed message is
received on an interface other than the one that the kernel would
normally use to send a message to the original destination, then any
route cache entries pointing out that interface are updated as well.
AFAICT it was motivated by a scenario where traffic  was intended to
be sent through a particular interface with SO_BINDTODEVICE set:
http://lists.openwall.net/netdev/2008/04/24/44

The correct thing to do would be to update the MTU on all the route
cache entries, including entries pointing to other interfaces on the
box (for example, consider a box with a default route pointing at
eth0, the packet too big coming in on eth1, and the original packet
having been sent through gre1 with SO_BINDTODEVICE; in this case, the
existing IPv4 code would silently fail). However, this is expensive
and doing it for the two common cases seems a reasonable compromise,
so it's probably worth doing it for IPv6 as well.

How about this patch instead?

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c2bd74c..c27464d 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1562,14 +1562,13 @@ out:
  *	i.e. Path MTU discovery
  */

-void rt6_pmtu_discovery(struct in6_addr *daddr, struct in6_addr *saddr,
-			struct net_device *dev, u32 pmtu)
+static void rt6_do_pmtu_disc(struct in6_addr *daddr, struct in6_addr *saddr,
+			     struct net *net, u32 pmtu, int ifindex)
 {
 	struct rt6_info *rt, *nrt;
-	struct net *net = dev_net(dev);
 	int allfrag = 0;

-	rt = rt6_lookup(net, daddr, saddr, dev->ifindex, 0);
+	rt = rt6_lookup(net, daddr, saddr, ifindex, 0);
 	if (rt == NULL)
 		return;

@@ -1637,6 +1636,28 @@ out:
 	dst_release(&rt->u.dst);
 }

+void rt6_pmtu_discovery(struct in6_addr *daddr, struct in6_addr *saddr,
+			struct net_device *dev, u32 pmtu)
+{
+	struct net *net = dev_net(dev);
+
+	/*
+	 * RFC 1981 states that a node "MUST reduce the size of the packets it
+	 * is sending along the path" that caused the Packet Too Big message.
+	 * Since it's not possible in the general case to determine which
+	 * interface was used to send the original packet, we update the MTU
+	 * on the interface that will be used to send future packets. We also
+	 * update the MTU on the interface that received the Packet Too Big in
+	 * case the original packet was forced out that interface with
+	 * SO_BINDTODEVICE or similar. This is the next best thing to the
+	 * correct behaviour, which would be to update the MTU on all
+	 * interfaces.
+	 */
+	rt6_do_pmtu_disc(daddr, saddr, net, pmtu, 0);
+	rt6_do_pmtu_disc(daddr, saddr, net, pmtu, dev->ifindex);
+}
+
+
 /*
  *	Misc support functions
  */
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html