Bug 89512

Description of problem:
When connected using CIPE, this protocol will not recognize too small packets 
passing through the tunnel, it will act as the packets never existed!!
I found on the CIPE developer's site that this is really a bug on all versions 
of cipe previous to the 1.5.4.
Bellow, I cut and pasted the information I found on 
http://sites.inka.de/bigred/archive/cipe-l/2002-01/msg00011.html

--------------------------------------------------------------------
To:  cipe-l 
Subject:  BUG: crasher [IMPORTANT PATCH] 
From:  Olaf Titz <olaf.de> 
Date:  Mon, 07 Jan 2002 21:17:18 +0100 

--------------------------------------------------------------------------------

This must be an old problem, why was it never found? :-) To my
knowledge it exists in all published versions of CIPE. It causes a
crash when CIPE receives too small packets. Thanks to Larry McVoy for
alerting me to this bug.

The attached patch is from the CVS but applies cleanly to 1.5.2.

Olaf

Index: cipe/sock.c
===================================================================
RCS file: /home/olaf/common-home/CVSrepos/security/cipe-linux/cipe/sock.c,v
retrieving revision 1.36
diff -u -r1.36 sock.c
--- cipe/sock.c 2001/12/29 20:23:04     1.36
+++ cipe/sock.c 2002/01/06 18:28:56
@@ -199,6 +199,11 @@
        goto framerr;
     }
 #endif
+    if (length<cipehdrlen+(c->sockshost?sizeof(struct sockshdr):0)) {
+        printk(KERN_INFO "%s: got short packet from %s\n", c->dev-
>name,
+               cipe_ntoa(saddr(skb)));
+       goto framerr;
+    }

     n=alloc_skb(skb->len, GFP_KERNEL);
     if (!n) {
@@ -390,10 +395,8 @@
     c->stat.rx_packets++;
     return NULL;

-#if 0
  framerr:
     ++c->stat.rx_frame_errors; /* slightly abuse this */
-#endif
  error:
     ++c->stat.rx_errors;
     if (n)

=== end of patch ===




Version-Release number of selected component (if applicable):
cipe-1.4.5-11

How reproducible:
Always

Steps to Reproduce:
To reproduce the problem, try a 'ping' with the '-s 0' option, this will 
produce icmp packets carrying 0 bytes of data, what generates a packet of only 
8 bytes (originated of the ICMP header).
This way:
ping -s 0 10.0.0.1 
Where 10.0.0.1 is the p-t-p addres of your peer machine.

Actual Results:  The ping will end with 100% of loss.
But if you simply try a 'ping 10.0.0.1' it will work. Why? Because the ping 
command sends by default a 56 bytes of data in each packet, which raises a 
packet with a total of 64 bytes.

Expected Results:  'ping -s 0' should work as it works for machines not using 
CIPE.

Additional info:

Of course when this problem happens on small ICMP packets this is not serious, 
but, when happening on small TCP packets(or other protocols), it could cause 
real problems.