From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; FreeBSD i386; U;) Gecko/0
Description of problem:
I can't quote chapter and verse, but the following behavior seems obviously
wrong, and it differs from another OS (Solaris) chosen at random for comparison.
Let A be a Linux box running RedHat 7.3, kernel=2.4.18-10bigmem.
When A receives a forged SYN from B, A sends B a SYN+ACK. B then sends A a RST,
since the initial SYN is forged.
You'd think it'd end there. But no, A keeps sending SYN+ACK to B for a long
time, despite receiving an RST in response to every one.
I will append tcpdumps showing how Linux and Solaris react differently. As one
would expect, Solaris stops the three-way handshake immediately after receiving
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Using libnet, forge a SYN from your own IP address to a Linux box.
Created attachment 89404 [details]
Solaris 7 reacting to a forged SYN
This is the behavior that seems reasonable to me.
Created attachment 89405 [details]
Linux reacting to a forged SYN
This is how Linux reacts. This seems wrong to me.
Created attachment 89406 [details]
Program to generate forged SYN
this is something that should be fixed in a more recent erratum kernel.
> this is something that should be fixed in a more recent erratum kernel.
I'm unclear whether that means that it *is* fixed or that it *will be* fixed.
(If the former -- in what version?)
it's believed to be fixed in the current erratum for 7.3, eg version 2.4.18-19.7.x
(which is the 3rd erratum since 2.4.18-10)
I confirm that this is fixed in 2.4.18-24.7.xbigmem. Thanks. Resolving