[PATCH] Fix ip6_build_xmit bug

[PATCH] Fix ip6_build_xmit bug

[Jon Grimm]

Wanting to play a bit with v6 fragmentation I started using ping6 to
send various message sizes.  Noticed that messages of sizes just under
where fragmentation would kick in, segfaulted in ip6_build_xmit().

Looks like ip6_build_xmit does not allocate room for the
dev->hard_header_len on the non-fragmentation path as is done in other
places.  The hard header len gets reserved even though room was not
allocated for it.  Consequenetly, the put of the raw data can overflow
the skb. 

Patch below for your consideration.

Best Regards,
Jon Grimm


--- lksctp-2.5/net/ipv6/ip6_output.c	Fri Mar 21 17:27:00 2003
+++ lksctp-2.5.work/net/ipv6/ip6_output.c	Fri Mar 21 17:24:38 2003
@@ -643,7 +643,8 @@
 		if (flags&MSG_PROBE)
 			goto out;
 		/* alloc skb with mtu as we do in the IPv4 stack for IPsec */
-		skb = sock_alloc_send_skb(sk, mtu, flags & MSG_DONTWAIT, &err);
+		skb = sock_alloc_send_skb(sk, mtu + dev->hard_header_len + 15,
+					  flags & MSG_DONTWAIT, &err);
 
 		if (skb == NULL) {
 			IP6_INC_STATS(Ip6OutDiscards);

ip6sec MTU/fragmentation issue / Was: Re: [PATCH] Fix ip6_build_xmit bug

[bert hubert]

On Fri, Mar 21, 2003 at 06:21:18PM -0600, Jon Grimm wrote:
> Wanting to play a bit with v6 fragmentation I started using ping6 to
> send various message sizes.  Noticed that messages of sizes just under
> where fragmentation would kick in, segfaulted in ip6_build_xmit().

Thanks, this fixes an observed issue here with segfaults in ping6, as you
described. I run 2.5.65.

There is another problem with ip6sec however where fragmentation fails.
Setting up an ip6sec connection and then sending bulk data freezes up a
connection. 

ping6 -s 1500 deef.ds9a.nl -n leads to:

20:16:18.125073 2001:888:1036:0:2a0:ccff:fec8:f25c >
2001:888:1036:0:2e0:18ff:fe23:cece: AH(spi=0x00003d54,sumlen=16,seq=0xbe):
ESP(spi=0x00003d55,seq=0xbe) (len 1504, hlim 64)

20:16:18.125129 2001:888:1036:0:2a0:ccff:fec8:f25c >
2001:888:1036:0:2e0:18ff:fe23:cece: AH(spi=0x00003d54,sumlen=16,seq=0xbf):
ESP(spi=0x00003d55,seq=0xbf) (len 112, hlim 64)

and a reply:

20:16:18.125474 2001:888:1036:0:2e0:18ff:fe23:cece >
2001:888:1036:0:2a0:ccff:fec8:f25c: AH(spi=0x00005fb4,sumlen=16,seq=0x82):
ESP(spi=0x00005fb5,seq=0x82) [hlim 0] (len 160)

The reply appears to be a bit short and is possibly an ICMP error. When I
configure ip6sec only in one way, I get this reply to fragmented ICMP echo
requests:

20:22:24.445157 2001:888:1036:0:2e0:18ff:fe23:cece >
2001:888:1036:0:2a0:ccff:fec8:f25c: icmp6: parameter problem next header -
octet 6 (len 116, hlim 64)

This is probably the same packet as we see encrypted above.

Working ping6, -s 1400, looks like this:

20:18:56.820699 2001:888:1036:0:2a0:ccff:fec8:f25c >
2001:888:1036:0:2e0:18ff:fe23:cece: AH(spi=0x00003d54,sumlen=16,seq=0x142):
ESP(spi=0x00003d55,seq=0x142) (len 1456, hlim 64)

20:18:56.821912 2001:888:1036:0:2e0:18ff:fe23:cece >
2001:888:1036:0:2a0:ccff:fec8:f25c: AH(spi=0x00005fb4,sumlen=16,seq=0xce):
ESP(spi=0x00005fb5,seq=0xce) [hlim 0] (len 1456)

Both of these hosts have your patch applied. So it seems that ip6sec
fragmentation has some issues.

Thanks.

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl                         Consulting

Re: [PATCH] Fix ip6_build_xmit bug

[David S. Miller]

   From: Jon Grimm <jgrimm2@us.ibm.com>
   Date: Fri, 21 Mar 2003 18:21:18 -0600

   Looks like ip6_build_xmit does not allocate room for the
   dev->hard_header_len on the non-fragmentation path as is done in other
   places.  The hard header len gets reserved even though room was not
   allocated for it.  Consequenetly, the put of the raw data can overflow
   the skb. 
   
   Patch below for your consideration.

Applied, but with a minor fix.  We now have a LL_RESERVED_SPACE(dev)
macro in include/linux/netdevice.h that gets this formula correct
and thus I have used it.

Thanks.

And yes we do know things are still slightly broken with ipv6
fragmentation wrt. IPSEC, and that is being actively worked on.
The IPV4 output path hacks just need to be duplicated into ipv6
before that will start working reliably.