netdev - Re: data-race in __tcp_alloc_md5sig_pool / tcp_alloc_md5sig

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 19 Aug 2022 14:23:53 -0700
From:   Eric Dumazet <edumazet@...gle.com>
To:     abhishek.shah@...umbia.edu
Cc:     David Miller <davem@...emloft.net>,
        David Ahern <dsahern@...nel.org>,
        Jakub Kicinski <kuba@...nel.org>, llvm@...ts.linux.dev,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        netdev <netdev@...r.kernel.org>, Paolo Abeni <pabeni@...hat.com>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        Andrii Nakryiko <andrii@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>, bpf <bpf@...r.kernel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        John Fastabend <john.fastabend@...il.com>,
        Martin KaFai Lau <kafai@...com>,
        KP Singh <kpsingh@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Song Liu <songliubraving@...com>, trix@...hat.com,
        Yonghong Song <yhs@...com>, Gabriel Ryan <gabe@...columbia.edu>
Subject: Re: data-race in __tcp_alloc_md5sig_pool / tcp_alloc_md5sig_pool

On Fri, Aug 19, 2022 at 8:40 AM Abhishek Shah
<abhishek.shah@...umbia.edu> wrote:
>
> Hi all,
>

Not sure why you included so many people in this report ?

You have not exactly said what could be the issue (other than the raw
kcsan report)

> We found a race involving the tcp_md5sig_pool_populated variable. Upon further investigation, we think that __tcp_alloc_md5sig_pool can be run multiple times before tcp_md5sig_pool_populated is set to true here. However, we are not sure. Please let us know what you think.

I think this is a false positive, because the data race is properly handled
with the help of tcp_md5sig_mutex.

We might silence it, of course, like many other existing data races.



>
> Thanks!
>
>
> --------------------Report--------------
>
> write to 0xffffffff883a2438 of 1 bytes by task 6542 on cpu 0:
>  __tcp_alloc_md5sig_pool+0x239/0x260 net/ipv4/tcp.c:4343
>  tcp_alloc_md5sig_pool+0x58/0xb0 net/ipv4/tcp.c:4352
>  tcp_md5_do_add+0x2c4/0x470 net/ipv4/tcp_ipv4.c:1199
>  tcp_v6_parse_md5_keys+0x473/0x490
>  do_tcp_setsockopt net/ipv4/tcp.c:3614 [inline]
>  tcp_setsockopt+0xda6/0x1be0 net/ipv4/tcp.c:3698
>  sock_common_setsockopt+0x62/0x80 net/core/sock.c:3505
>  __sys_setsockopt+0x2d1/0x450 net/socket.c:2180
>  __do_sys_setsockopt net/socket.c:2191 [inline]
>  __se_sys_setsockopt net/socket.c:2188 [inline]
>  __x64_sys_setsockopt+0x67/0x80 net/socket.c:2188
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x44/0xae
>
> read to 0xffffffff883a2438 of 1 bytes by task 6541 on cpu 1:
>  tcp_alloc_md5sig_pool+0x15/0xb0 net/ipv4/tcp.c:4348
>  tcp_md5_do_add+0x2c4/0x470 net/ipv4/tcp_ipv4.c:1199
>  tcp_v4_parse_md5_keys+0x42f/0x500 net/ipv4/tcp_ipv4.c:1303
>  do_tcp_setsockopt net/ipv4/tcp.c:3614 [inline]
>  tcp_setsockopt+0xda6/0x1be0 net/ipv4/tcp.c:3698
>  sock_common_setsockopt+0x62/0x80 net/core/sock.c:3505
>  __sys_setsockopt+0x2d1/0x450 net/socket.c:2180
>  __do_sys_setsockopt net/socket.c:2191 [inline]
>  __se_sys_setsockopt net/socket.c:2188 [inline]
>  __x64_sys_setsockopt+0x67/0x80 net/socket.c:2188
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x44/0xae
>
> Reported by Kernel Concurrency Sanitizer on:
> CPU: 1 PID: 6541 Comm: syz-executor2-n Not tainted 5.18.0-rc5+ #107
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
>
>
> Reproducing Inputs
>
> Input CPU 0:
> r0 = socket(0xa, 0x1, 0x0)
> setsockopt$inet_tcp_TCP_MD5SIG(r0, 0x6, 0xe, &(0x7f0000000000)={@...={{0xa, 0x0, 0x0, @private0}}, 0x0, 0x0, 0x10, 0x0, "a04979dcb0f6e3666c36f59053376c1d2e245fbad5b4749a8c55dda1bd819ec87afb7f5ac2483f179675d3c23fdba661afcca7cca5661a7b52ac11cc8085800c2c0d8e7de309eb57b89292880a563154"}, 0xd8)
> setsockopt$inet_tcp_TCP_MD5SIG(r0, 0x6, 0xe, &(0x7f0000000100)={@...={{0xa, 0x0, 0x0, @loopback}}, 0x0, 0x0, 0x28, 0x0, "f386ea32b026420a2c65ea375667090000000000000000a300001e81f9c22181fe9cef51a4070736c7a33d08c1dd5c35eb9b0e6c6aa490d4f1b18f7b09103bf18619b49a9ce10f4bd98e0b00"}, 0xd8)
>
> Input CPU 1:
> r0 = socket$inet_tcp(0x2, 0x1, 0x0)
> setsockopt$inet_tcp_TCP_MD5SIG(r0, 0x6, 0xe, &(0x7f0000000080)={@...{{0x2, 0x0, @remote}}, 0x0, 0x0, 0x47, 0x0, "2a34e559cc66f8b453edeb61450c3899cc1d1304f0e5f1758293ddd3597b84447d3056ed871ae397b0fd27a54e4ff8ba83f0cf3e5f323acb74f974c0b87333e0570e9019d8fdcf0bc1044a5e96d68296"}, 0xd8)