netdev - Re: [PATCH] net: ip_finish_output_gso: If skb_gso_network_seglen exceeds MTU, do segmentation even for non IPSKB

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]

Date:	Tue, 5 Jul 2016 15:03:27 +0200
From:	Florian Westphal <fw@...len.de>
To:	Shmulik Ladkani <shmulik.ladkani@...ellosystems.com>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Florian Westphal <fw@...len.de>,
	Eric Dumazet <edumazet@...gle.com>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	shmulik.ladkani@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH] net: ip_finish_output_gso: If skb_gso_network_seglen
 exceeds MTU, do segmentation even for non IPSKB_FORWARDED skbs

Shmulik Ladkani <shmulik.ladkani@...ellosystems.com> wrote:
> Given:
>  - tap0, vxlan0 enslaved under a bridge
>  - eth0 is the tunnel underlay having small mtu (e.g. 1400)
> 
> Assume GSO skbs arriving from tap0 having a gso_size as determined by
> user-provided virtio_net_hdr (e.g. 1460 corresponding to VM mtu of 1500).
> 
> After encapsulation these skbs have skb_gso_network_seglen that exceed
> underlay ip_skb_dst_mtu.
> 
> These skbs are accidentally passed to ip_finish_output2 AS IS; however
> each final segment (either segmented by validate_xmit_skb of eth0, or
> by eth0 hardware UFO) would be larger than eth0 mtu.
> As a result, those above-mtu segments get dropped on certain underlay
> networks.
> 
> The expected behavior in such a setup would be segmenting the skb first,
> and then fragmenting each segment according to dst mtu, and finally
> passing the resulting fragments to ip_finish_output2.
> 
> 'ip_finish_output_gso' already supports this "Slowpath" behavior,
> but it is only considered if IPSKB_FORWARDED is set.
> 
> However in the bridged case, IPSKB_FORWARDED is off, and the "Slowpath"
> behavior is not considered.

I placed this test there under the assumption that L2 bridges have
the same MTU on all bridge ports, so we'd only need to consider routing
case.

How does work if e.g. 1460-sized udp packet arrives on tap0?
Do we fragment (possibly ignoring DF?)

How does it work for non-ip protocols?

(Or did I misunderstand this setup...?)