Max Krasnyansky wrote:
Hi Stephen,
Looks like a something wrong with tun driver on 2.6.11
Thanks for forwarding this. I'll take a look at it.
As far as I remember nothing really changed in the TUN write logic.
Must be some other changes broke it.
This check is wrong, gcc optimizes it away:
if ((len -= sizeof(pi)) > len)
return -EINVAL;
This could be responsible for the BUG. If len is 2 or 3 and TUN_NO_PI
isn't set it underflows. alloc_skb() allocates len + 2, which is 0 or
1 byte. skb_reserve tries to reserve 2 bytes and things explode in
skb_put.
Regards
Patrick
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/03/04 19:41:29+01:00 kaber@xxxxxxxxxxxx
# [TUN]: Fix check for underflow
#
# Signed-off-by: Patrick McHardy <kaber@xxxxxxxxx>
#
# drivers/net/tun.c
# 2005/03/04 19:41:20+01:00 kaber@xxxxxxxxxxxx +1 -1
# [TUN]: Fix check for underflow
#
# Signed-off-by: Patrick McHardy <kaber@xxxxxxxxx>
#
diff -Nru a/drivers/net/tun.c b/drivers/net/tun.c
--- a/drivers/net/tun.c 2005-03-04 19:41:56 +01:00
+++ b/drivers/net/tun.c 2005-03-04 19:41:56 +01:00
@@ -229,7 +229,7 @@
size_t len = count;
if (!(tun->flags & TUN_NO_PI)) {
- if ((len -= sizeof(pi)) > len)
+ if ((len -= sizeof(pi)) > count)
return -EINVAL;
if(memcpy_fromiovec((void *)&pi, iv, sizeof(pi)))
|