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: <20140220025443.GH1179@order.stressinduktion.org>
Date:	Thu, 20 Feb 2014 03:54:43 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Wolfgang Walter <linux@...m.de>, netdev@...r.kernel.org,
	xiyou.wangcong@...il.com, eric.dumazet@...il.com
Subject: Re: linux 3.13: problems with isatap tunnel device and UFO

On Thu, Feb 20, 2014 at 03:44:18AM +0100, Hannes Frederic Sowa 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...

In-tunnel IPv6 fragmentation ids don't seem to be random at all... :/

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