netdev - Re: question: update_pmtu doesn't update dst mtu

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: <20140408145718.GC27255@order.stressinduktion.org>
Date:	Tue, 8 Apr 2014 16:57:19 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	"Ilya V. Matveychikov" <i.matveychikov@...uritycode.ru>
Cc:	netdev@...r.kernel.org
Subject: Re: question: update_pmtu doesn't update dst mtu

On Tue, Apr 08, 2014 at 01:03:43PM +0400, Ilya V. Matveychikov wrote:
> Just another related question that gets me into trouble. Imagine that there is
> an SKB that wants to be transmitted via that tunnel. Let's say that when it
> comes to the TUNNEL device it has an MTU1 value. Now, someone updates the PMTU
> for the route and mtu decreasing from MTU1 to MTU2, so MTU2 < MTU1.
> 
> Given that, I suppose that our SKB must be (re)fragmented with ip_fragment as
> it's size might be slightly bigger then the path can pass. The problem is that
> ip_fragment uses dst_mtu(skb_dst(skb)) to determine the fragment size but it
> still has MTU1 value as even update_pmtu(MTU2) was called as it doesn't leads to
> real dst MTU updating.
> 
> So the question is do I need to relookup the route or can I use the following
> hack before ip_fragment:
> 
> 	// dst_mtu(dst) shows MTU1
> 	dst->ops->update_pmtu(dst, ..., MTU2)
> 	...
> 	skb_rtable(skb)->rt_pmtu = MTU2;

This might be a cached dst and you would alter the mtu for more nexthops than
you intended.

> 	dst_set_expires(dst, 1);

With this you won't get around the time_after_eq check. You would have to
tweak it manually to not retrieve dst_metrics value (this is what you
intended?).

> 	...
> 	// now, ip_fragment knows about real MTU value
> 	ip_fragment(skb, output...)

Check if you can something do like
skb_dst_drop(skb);
new_dst = ip_route_output*(..., &fl4, ...);
skb_dst_set(_noref)(skb, new_dst);

This should be a very unlikely path, I assume, so should not degrade
performance that much.

I wonder why you update the mtu in the output path.

Bye,

  Hannes

--
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