An obscure bug in tcp_ipv4.c

Nimrod Zimerman (zimerman@deskmail.com)
Wed, 25 Nov 1998 22:02:00 +0200


Hello.

I found what I consider to be a small obscure and fairly meaningless bug in
kernel 2.1.129, tcp_ipv4.c, when assigning a socket number (tcp_good_socknum).
I'm reporting it just for completeness, since it really doesn't matter in the
real world.

When trying to locate an unused socket, a calculation of the number of
potentially unused sockets is made, using 'high - low'. This is incorrect, and
should be 'high - low + 1'.

This bug proves to be a problem in either of the following two cases:
1. 'high' and 'low' are the same number. Might be relevant in the real world
in some extremely weird situation - a machine that only allows one
local TCP socket at any given time. In this case, no sockets
will ever be found.
2. All sockets are used, excluding one, and tcp_port_rover is set such that
the next socket about to be checked is used. In this case, an unused socket
won't be found, even though one exists. In the real world this doesn't
really matter, because one socket more or less doesn't make a difference (it
just introduces a bit of randomness...).

The enclosed patch fixes this, and is very obvious:

--- linux/net/ipv4/tcp_ipv4.c.ORIG Sat Nov 7 21:00:32 1998
+++ linux/net/ipv4/tcp_ipv4.c Wed Nov 25 20:29:56 1998
@@ -265,7 +265,7 @@
struct tcp_bind_bucket *tb;
int low = sysctl_local_port_range[0];
int high = sysctl_local_port_range[1];
- int remaining = high - low;
+ int remaining = high - low + 1;
int rover;

SOCKHASH_LOCK();

---

Nimrod

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/