netdev - Re: Expected result when racing listen(2) on two sockets bound to the same address

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>] [day] [month] [year] [list]

Message-ID: <4887534b-cac3-65b5-8c9f-f736c1e56ba3@virtuozzo.com>
Date:   Wed, 23 May 2018 15:44:22 +0300
From:   Kirill Tkhai <ktkhai@...tuozzo.com>
To:     Alexander Kurtz <alexander@...tz.be>, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: Expected result when racing listen(2) on two sockets bound to the
 same address

Hi,

On 23.05.2018 14:15, Alexander Kurtz wrote:
> [Please keep me CC'ed; I'm not subscribed to the list]
> 
> Hi!
> 
> The program shown below (also available at [0]) does the following:
> 
>  * Create two sockets
>  * Enable SO_REUSEADDR on both
>  * Bind both sockets to [::1]:12345
>  * Spawn two threads which both call listen(2) on one socket each
>  * Check that at least one thread succeeded
> 
> Unfortunately, when running this program on Linux 4.16, it is sometimes
> possible that neither thread succeeds in calling listen(2):
> 
>     $ uname -a
>     Linux shepard 4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29) x86_64 GNU/Linux
>     $ time make
>     cc -Wall -Wextra -pedantic -Werror -O3    listenrace.c  -lpthread -o listenrace
>     for i in `seq 10000`; do ./listenrace; done
>     listenrace: listenrace.c:58: main: Assertion `result1 == 0 || result2 == 0' failed.
>     Aborted
>     listenrace: listenrace.c:58: main: Assertion `result1 == 0 || result2 == 0' failed.
>     Aborted
>     listenrace: listenrace.c:58: main: Assertion `result1 == 0 || result2 == 0' failed.
>     Aborted
> 
>     real	0m8.201s
>     user	0m6.801s
>     sys	0m2.141s
>     $ 
> 
> As can be seen, on 3 runs (out of 10000) calling listen(2) failed in
> *both* threads. Is this to be expected (i.e. "don't do this then") or
> could this be some race condition in the Linux kernel?

At the first sight, it is in kernel and is expected:

inet_csk_listen_start()
{
	/* There is race window here: we announce ourselves listening,
	 * but this transition is still not validated by get_port().
	 * It is OK, because this socket enters to hash table only
	 * after validation is complete.
	 */
        inet_sk_state_store(sk, TCP_LISTEN);
        if (!sk->sk_prot->get_port(sk, inet->inet_num)) {

}

CC netdev.

Kirill