Hide Forgot
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 the RST. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Using libnet, forge a SYN from your own IP address to a Linux box. Additional info:
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 Requires libnet
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 CURRENTRELEASE.