netdev - Re: linux 3.13: problems with isatap tunnel device and UFO

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: <20140217160916.GE22833@order.stressinduktion.org>
Date:	Mon, 17 Feb 2014 17:09:16 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Wolfgang Walter <linux@...m.de>
Cc:	netdev@...r.kernel.org, xiyou.wangcong@...il.com
Subject: Re: linux 3.13: problems with isatap tunnel device and UFO

[+Cc Cong Wang]

Hi Cong!

In commit d949d826c09fb ("ipv6: Add generic UDP Tunnel segmentation") you
patched ip6_offload.c:

@@ -126,7 +128,7 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
                ipv6h = ipv6_hdr(skb);
                ipv6h->payload_len = htons(skb->len - skb->mac_len -
                                           sizeof(*ipv6h));
-               if (proto == IPPROTO_UDP) {
+               if (!tunnel && proto == IPPROTO_UDP) {
                        unfrag_ip6hlen = ip6_find_1stfragopt(skb, &prevhdr);
                        fptr = (struct frag_hdr *)(skb_network_header(skb) +
                                unfrag_ip6hlen);

I wonder about the !tunnel exception. This now seems to be a problem in sit
ufo output path, where we don't update fragmentation offsets any more thus
generating invalid frames.

I am not too firm with segmentation in case of tunnels but don't we need to
always update the fragmentation offset no matter what, if upper gso callback
produced more segments?

I'll try to dig deeper...

Thanks,

  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