[PATCH] Fix for PPP Kernel panic?

["B. James Phillippe" <bryan terran org>]

Hello,

	I have been plagued by kernel panics in Linux-2.1.1xx up through
2.1.131-ac9.  My system is a RedHat-5.X/rawhide DEC AlphaStation with
ppp-2.3.5 connected to the Internet 24/7.  It seems several other Alpha
folks have reported the same problem.  By using a -g compiled kernel and
gdb, I was able to pinpoint the location to ppp.c, line 2051.  Once there,
the problem is quite obvious:

/*
 * Process the receipt of an VJ Compressed frame
 */
static int
rcv_proto_vjc_comp(struct ppp *ppp, struct sk_buff *skb)
{
        int new_count;

        CHECK_PPP(0);
        if ((ppp->flags & SC_REJ_COMP_TCP) || ppp->slcomp == NULL)
                return 0;
        new_count = slhc_uncompress(ppp->slcomp, skb->data + PPP_HDRLEN,
                                    skb->len - PPP_HDRLEN);
        if (new_count < 0) {
                if (ppp->flags & SC_DEBUG)
                        printk(KERN_NOTICE
                               "ppp: error in VJ decompression\n");
                return 0;
        }
        skb_put(skb, new_count + PPP_HDRLEN - skb->len);
        return rcv_proto_ip(ppp, skb);
}

If we look at slhc_uncompress in drivers/net/slhc.c, we see that "0" is
returned on error (there are several possible error conditions).  As soon
as there is an error, new_count will be set to 0.  The test of it being
less than 0 will fail, so we skb_put with a length of "0 + 4 - skb->len";
usually a negative number.  Because skb_put expects an unsigned argument,
now we have a really huge number.  Boom.  My suggested fix is:

--- drivers/net/ppp.c.orig	Mon Dec 14 00:18:06 1998
+++ drivers/net/ppp.c	Mon Dec 14 00:47:45 1998
@@ -2041,7 +2041,7 @@
 		return 0;
 	new_count = slhc_uncompress(ppp->slcomp, skb->data + PPP_HDRLEN,
 				    skb->len - PPP_HDRLEN);
-	if (new_count < 0) {
+	if (!new_count) {
 		if (ppp->flags & SC_DEBUG)
 			printk(KERN_NOTICE
 			       "ppp: error in VJ decompression\n");

This should be okay because there is a separate check in slhc_uncompress
for negative values of len.  I don't know why the Intel people haven't run
into this yet; this should bite everyone.

thanks,
-bp
--
B. James Phillippe	. bryan@terran.org
Linux Engineer/Admin	. http://www.terran.org/~bryan
Member since 1.1.59	. finger:bryan@earth.terran.org