Description of problem: Make sure, that TCP has a nonzero RTT estimation after three-way handshake. Currently, a listening TCP has a value of 0 for srtt, rttvar and rto right after the three-way handshake is completed with TCP timestamps disabled. This will lead to corrupt RTO recalculation and retransmission flood when RTO is recalculated on backoff reversion as introduced in "Revert RTO on ICMP destination unreachable" (f1ecd5d9e7366609d640ff4040304ea197fbc618). This behaviour can be provoked by connecting to a server which "responds first" (like SMTP) and rejecting every packet after the handshake with dest-unreachable, which will lead to softirq load on the server (up to 30% per socket in some tests). Thanks to Ilpo Jarvinen for providing debug patches and to Denys Fedoryshchenko for reporting and testing. Changes since v3: Removed bad characters in patchfile. Reported-by: Denys Fedoryshchenko <denys.lb> Signed-off-by: Damian Lukowski <damian.de> Signed-off-by: David S. Miller <davem> Upstream commit: http://git.kernel.org/linus/598856407d4e20ebb4de01a91a93d89325924d43 "Revert RTO on ICMP destination unreachable" was introduced in: http://git.kernel.org/linus/f1ecd5d9e7366609d640ff4040304ea197fbc618 (v2.6.32-rc1) Reference: http://www.securityfocus.com/bid/38355
Not vulnerable. This issue did not affect the versions of the Linux kernel as shipped with Red Hat Enterprise Linux 3, 4, 5 and Red Hat Enterprise MRG. Shipped kernels do not include upstream commit f1ecd5d9e that introduced the problem.
kernel-2.6.32.9-67.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/kernel-2.6.32.9-67.fc12
Fixed in Fedora: 2.6.32.9-37.fc11 2.6.32.9-66.fc12 We can't mark this bug as fixed in Bodhi because it transforms the entire update into a security update even though no released Fedora kernel has this bug.