netdev - Re: [PATCH net] ipv6: reuse ip6_frag_id from ip6_ufo_append

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] [day] [month] [year] [list]

Message-ID: <20140226134245.GC24855@order.stressinduktion.org>
Date:	Wed, 26 Feb 2014 14:42:45 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH net] ipv6: reuse ip6_frag_id from ip6_ufo_append_data

On Tue, Feb 25, 2014 at 02:09:11PM -0500, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@...essinduktion.org>
> Date: Sat, 22 Feb 2014 06:52:31 +0100
> 
> > Hi David!
> > 
> > On Sat, Feb 22, 2014 at 12:28:55AM -0500, David Miller wrote:
> >> From: Hannes Frederic Sowa <hannes@...essinduktion.org>
> >> Date: Fri, 21 Feb 2014 02:55:35 +0100
> >> 
> >> > Currently we generate a new fragmentation id on UFO segmentation. It
> >> > is pretty hairy to identify the correct net namespace and dst there.
> >> > Especially tunnels use IFF_XMIT_DST_RELEASE and thus have no skb_dst
> >> > available at all.
> >> > 
> >> > This causes unreliable or very predictable ipv6 fragmentation id
> >> > generation while segmentation.
> >> > 
> >> > Luckily we already have pregenerated the ip6_frag_id in
> >> > ip6_ufo_append_data and can use it here.
> >> > 
> >> > Signed-off-by: Hannes Frederic Sowa <hannes@...essinduktion.org>
> >> 
> >> Applied, thanks Hannes.
> > 
> > Could you also get this at least into 3.13, as sit tunnels enable gso
> > by default there?
> 
> Queueud up for -stable, thanks Hannes.

Just FYI:

While doing some more code review on this part (and in the history), it
seemes we can actually call ipv6_select_ident with ipv4 dsts from time
to time thus using just the random memory available there to generate an
ipv6 address. So this fix is appropriate for all kernels from v2.6.32 on.

We can now remove DST_NOPEER in net-next which was just introduced
because of a bug in this logic and simplify ipv6_select_ident in net-next
(patches coming after net merge to net-next).

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