bug in tcp/ip stack

bug in tcp/ip stack

[john]

I tracked down something that appears to be a small bug in networking code.
The way in witch i can reproduce it a complex one but it works 100%, so 
here comes the details:

I noticed strange packets on my fw coming from mail server with RST/ACK 
flags set coming from source port with no one listening on it and no 
connection attempts made to them from outside.
There are few messages on forums describing same problem and calling 
them alien ACK/RST packets.

Postfix mail server gives this behavior if for some reason client resets 
connection but some packets from client arrives after the RST, the serer 
box responds with RST and then with RST/ACK (with the wrong source port 
number).

Here is packet dump

1    0.000000    10.0.0.254    10.0.0.68    TCP    50000 > smtp [SYN] 
Seq=0 Len=0
2    0.001036    10.0.0.68    10.0.0.254    TCP    smtp > 50000 [SYN, 
ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
3    0.001096    10.0.0.254    10.0.0.68    TCP    50000 > smtp [ACK] 
Seq=1 Ack=1 Win=1500 Len=0
4    0.001125    10.0.0.254    10.0.0.68    SMTP    Command: EHLO localhost
5    0.001150    10.0.0.254    10.0.0.68    TCP    50000 > smtp [RST] 
Seq=17 Len=0
6    0.001175    10.0.0.254    10.0.0.68    TCP    50000 > smtp [FIN, 
ACK] Seq=17 Ack=1 Win=1500 Len=0
7    0.001251    10.0.0.68    10.0.0.254    TCP    smtp > 50000 [ACK] 
Seq=1 Ack=17 Win=5840 Len=0
8    0.001284    10.0.0.68    10.0.0.254    TCP    smtp > 50000 [RST] 
Seq=1 Len=0
!!!9    0.218427    10.0.0.68    10.0.0.254    TCP    32768 > 50000 
[RST, ACK] Seq=0 Ack=0 Win=5840 Len=0

It is not the postfix bug, it is present in current 2.6.x and 2.4.x 
kernel versions but not in the 2.2.x tree, so after investigation i 
found it was introduced in 2.4.0-test9-pre3 back in year 2000 and 
survived for 7 years WOW :)


Whole 2.4.0-test9-pre3 diff is pretty big, but i managed to find lines 
responsible for this,
they are located in include/net/tcp.h

in function tcp_enter_cwr

if (sk->prev && !(sk->userlocks&SOCK_BINDPORT_LOCK))
                      tcp_put_port(sk);



It is not a big problem but under some setups the fw's conntrack table 
can get filled pretty quickly,  because wrong port number changes every 
time.

Can, you please check this out?

Evalds