netdev - Re: [net] tipc: fix successful connect() but timed out

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 10 Feb 2020 10:25:13 +0100 (CET)
From:   David Miller <davem@...emloft.net>
To:     tuong.t.lien@...tech.com.au
Cc:     jmaloy@...hat.com, maloy@...jonn.com, ying.xue@...driver.com,
        netdev@...r.kernel.org, tipc-discussion@...ts.sourceforge.net
Subject: Re: [net] tipc: fix successful connect() but timed out

From: Tuong Lien <tuong.t.lien@...tech.com.au>
Date: Mon, 10 Feb 2020 15:35:44 +0700

> In commit 9546a0b7ce00 ("tipc: fix wrong connect() return code"), we
> fixed the issue with the 'connect()' that returns zero even though the
> connecting has failed by waiting for the connection to be 'ESTABLISHED'
> really. However, the approach has one drawback in conjunction with our
> 'lightweight' connection setup mechanism that the following scenario
> can happen:
 ...
> Upon the receipt of the server 'ACK', the client becomes 'ESTABLISHED'
> and the 'wait_for_conn()' process is woken up but not run. Meanwhile,
> the server starts to send a number of data following by a 'close()'
> shortly without waiting any response from the client, which then forces
> the client socket to be 'DISCONNECTING' immediately. When the wait
> process is switched to be running, it continues to wait until the timer
> expires because of the unexpected socket state. The client 'connect()'
> will finally get ‘-ETIMEDOUT’ and force to release the socket whereas
> there remains the messages in its receive queue.
> 
> Obviously the issue would not happen if the server had some delay prior
> to its 'close()' (or the number of 'DATA' messages is large enough),
> but any kind of delay would make the connection setup/shutdown "heavy".
> We solve this by simply allowing the 'connect()' returns zero in this
> particular case. The socket is already 'DISCONNECTING', so any further
> write will get '-EPIPE' but the socket is still able to read the
> messages existing in its receive queue.
> 
> Note: This solution doesn't break the previous one as it deals with a
> different situation that the socket state is 'DISCONNECTING' but has no
> error (i.e. sk->sk_err = 0).
> 
> Fixes: 9546a0b7ce00 ("tipc: fix wrong connect() return code")
> Acked-by: Ying Xue <ying.xue@...driver.com>
> Acked-by: Jon Maloy <jon.maloy@...csson.com>
> Signed-off-by: Tuong Lien <tuong.t.lien@...tech.com.au>

Applied.