Fix ip6_build_xmit bug

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

@@ -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);

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

From: Jon Grimm <[email protected]>
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.