Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Message-ID: <1a97421c-c1f3-4974-ac81-9bc1e224f797@gmail.com>
Date:   Thu, 14 Dec 2023 11:56:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH net] net: Return error from sk_stream_wait_connect() if
 sk_wait_event() fails
To:     Shigeru Yoshida <syoshida@redhat.com>, davem@davemloft.net,
        kuba@kernel.org, pabeni@redhat.com
Cc:     netdev@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20231214050922.3480023-1-syoshida@redhat.com>
Content-Language: en-US
From:   Eric Dumazet <eric.dumazet@gmail.com>
In-Reply-To: <20231214050922.3480023-1-syoshida@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 12/14/23 06:09, Shigeru Yoshida wrote:
> The following NULL pointer dereference issue occurred:
>
> BUG: kernel NULL pointer dereference, address: 0000000000000000
> <...>
> RIP: 0010:ccid_hc_tx_send_packet net/dccp/ccid.h:166 [inline]
> RIP: 0010:dccp_write_xmit+0x49/0x140 net/dccp/output.c:356
> <...>
> Call Trace:
>   <TASK>
>   dccp_sendmsg+0x642/0x7e0 net/dccp/proto.c:801
>   inet_sendmsg+0x63/0x90 net/ipv4/af_inet.c:846
>   sock_sendmsg_nosec net/socket.c:730 [inline]
>   __sock_sendmsg+0x83/0xe0 net/socket.c:745
>   ____sys_sendmsg+0x443/0x510 net/socket.c:2558
>   ___sys_sendmsg+0xe5/0x150 net/socket.c:2612
>   __sys_sendmsg+0xa6/0x120 net/socket.c:2641
>   __do_sys_sendmsg net/socket.c:2650 [inline]
>   __se_sys_sendmsg net/socket.c:2648 [inline]
>   __x64_sys_sendmsg+0x45/0x50 net/socket.c:2648
>   do_syscall_x64 arch/x86/entry/common.c:51 [inline]
>   do_syscall_64+0x43/0x110 arch/x86/entry/common.c:82
>   entry_SYSCALL_64_after_hwframe+0x63/0x6b
>
> sk_wait_event() returns an error (-EPIPE) if disconnect() is called on the
> socket waiting for the event. However, sk_stream_wait_connect() returns
> success, i.e. zero, even if sk_wait_event() returns -EPIPE, so a function
> that waits for a connection with sk_stream_wait_connect() may misbehave.
>
> In the case of the above DCCP issue, dccp_sendmsg() is waiting for the
> connection. If disconnect() is called in concurrently, the above issue
> occurs.
>
> This patch fixes the issue by returning error from sk_stream_wait_connect()
> if sk_wait_event() fails.
>
> Fixes: 419ce133ab92 ("tcp: allow again tcp_disconnect() when threads are waiting")
> Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>

Reviewed-by: Eric Dumazet <edumazet@google.com>