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]

Date:	Thu, 20 Feb 2014 16:43:41 -0800
From:	Cong Wang <xiyou.wangcong@...il.com>
To:	Wolfgang Walter <linux@...m.de>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Cong Wang <xiyou.wangcong@...il.com>,
	Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: linux 3.13: problems with isatap tunnel device and UFO

On Wed, Feb 19, 2014 at 6:44 PM, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
> On Mon, Feb 17, 2014 at 05:09:16PM +0100, Hannes Frederic Sowa wrote:
>> [+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?
>
> Not perfect nor clean (well, I don't know).
>
> The idea is to have the segmentation at the first guessed tunnel
> header cut. I don't know how to deal with stacked tunnels yet, I guess
> we need to have a bit more state in the skb. Just to maybe keep the discussion
> going...

Does the following patch help?

View attachment "tmp.diff" of type "text/plain" (1484 bytes)