Most recent kernel where this bug did not occur: all versions have this problem, probably Distribution: Hardware Environment: 2 hosts connected via network Software Environment: Problem Description: There is a race condition in tcp_sendmsg() function. It checks that connection is not established yet and calls sk_stream_wait_connect() in this case. sk_stream_wait_connect() checks TCP state again, and this state may be changed from the previous check (connection have just established). In this situation, send() syscall seturns -1 with EPIPE instead of sending data. Next calls to send() will work without problems. Steps to reproduce: 1. On the host2, set up iptables to drop all TCP packets from the host1. Set up a TCP server listening on some_port. 2. On the host1, call non-blocking connect() on a TCP socket to host2:some_port. 3. On the host1, call send() on this socket. Notice that the socket is not connected yet. 4. Simultaneously with step 3, remove the firewall on the host2 to move the connection to ESTABLISHED state. 5. Expect send() to return success when the connection become established. In most cases, it is so. Sometimes, I get -1 with EPIPE. I've added a printk() into sk_stream_wait_connect() just after if ((1 << sk->sk_state) & ~(TCPF_SYN_SENT | TCPF_SYN_RECV)) and I see that -EPIPE is returned because of this check. I have a test to reproduce this race condion, but the test is under proprietary license (non-distributable). Feel free to ask me to try any patch.
Begin forwarded message: Date: Thu, 16 Mar 2006 07:22:54 -0800 From: bugme-daemon@bugzilla.kernel.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 6233] New: race condition in tcp_sendmsg when connection became established http://bugzilla.kernel.org/show_bug.cgi?id=6233 Summary: race condition in tcp_sendmsg when connection became established Kernel Version: 2.6.15.6 Status: NEW Severity: normal Owner: shemminger@osdl.org Submitter: Alexandra.Kossovsky@oktetlabs.ru Most recent kernel where this bug did not occur: all versions have this problem, probably Distribution: Hardware Environment: 2 hosts connected via network Software Environment: Problem Description: There is a race condition in tcp_sendmsg() function. It checks that connection is not established yet and calls sk_stream_wait_connect() in this case. sk_stream_wait_connect() checks TCP state again, and this state may be changed from the previous check (connection have just established). In this situation, send() syscall seturns -1 with EPIPE instead of sending data. Next calls to send() will work without problems. Steps to reproduce: 1. On the host2, set up iptables to drop all TCP packets from the host1. Set up a TCP server listening on some_port. 2. On the host1, call non-blocking connect() on a TCP socket to host2:some_port. 3. On the host1, call send() on this socket. Notice that the socket is not connected yet. 4. Simultaneously with step 3, remove the firewall on the host2 to move the connection to ESTABLISHED state. 5. Expect send() to return success when the connection become established. In most cases, it is so. Sometimes, I get -1 with EPIPE. I've added a printk() into sk_stream_wait_connect() just after if ((1 << sk->sk_state) & ~(TCPF_SYN_SENT | TCPF_SYN_RECV)) and I see that -EPIPE is returned because of this check. I have a test to reproduce this race condion, but the test is under proprietary license (non-distributable). Feel free to ask me to try any patch. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
A patch for this issue went into Linus' tree and will therefore be in 2.6.16-rc7.