[Patch] Netlink BUG() on AMD64

From: Jan Kasprzak
Date: Wed Feb 11 2004 - 13:15:20 EST


Jan Kasprzak wrote:
: I have got kernel BUG() while running the "ip rule list" command
: on my dual AMD64 box with 2.6.2 kernel. I have a blacklist of IP
: addresses, and I have one IP rule for each of this addresses:
:
: ip rule add pref 500 from x.y.z.a dev $UPLINK_DEV blackhole
:
: I have about 200 such rules (with different x.y.z.a IPv4 addresses,
: but all with the same preference of 500 and same $UPLINK_DEV - currently
: eth3). I have measured that when I add less than 60 such rules, I do not
: get BUG() during "ip rule list" command. When I add 60 or more,
: I get overflow in skb_put(). So the kernel is definitely overflowing
: something.

The problem is that in fib_rules.c there is an attempt to
skb_put() a negative increment. Which is OK on platforms where sizeof(unsigned)
== sizeof(void *). skb_put() has its second argument as unsigned int,
so instead of adding a -36 bytes here, it adds 4294967260 bytes to the
skb->tail, which extends it further than skb->end, which causes the
BUG() I have mentioned. The solution would be to change the argument
of skb_put() and friends to be either long or signed int, or to call
skb_trim() instead of skb_put in fib_rules.c instead.

I suggest the following patch, but all occurences of
nlmsg_failure: and rtattr_failure: labels should be checked for a similar
problem.

--- linux-2.6.2/net/ipv4/fib_rules.c.orig 2004-02-11 18:55:58.000000000 +0100
+++ linux-2.6.2/net/ipv4/fib_rules.c 2004-02-11 19:03:08.319215408 +0100
@@ -438,7 +438,7 @@

nlmsg_failure:
rtattr_failure:
- skb_put(skb, b - skb->tail);
+ skb_trim(skb, b - skb->data);
return -1;
}

Please apply or let me know what the proper fix should be.

-Yenya

--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ |
Any compiler or language that likes to hide things like memory allocations
behind your back just isn't a good choice for a kernel. --Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/