Re: [PATCH stable 6.1.y] tcp: fix potential race in tcp_v6_syn_recv_sock()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [Low] The patch adds a new argument to the `syn_recv_sock` function pointer in `struct inet_connection_sock_af_ops` but fails to update the DCCP subsystem, breaking the build when `CONFIG_IP_DCCP` is enabled.

Pre-existing issues:
- [Critical] Use-After-Free and double-free of the listener's IPv6 options on routing failure during IPv4-mapped socket creation.
- [High] The DCCP subsystem contains the identical race condition for IPv4-mapped IPv6 sockets that this patch intended to fix for TCP.
--

commit 0524a546fd92e10009336d36766fbc7fa6b854ac
Author: Eric Dumazet <edumazet@google.com>

tcp: fix potential race in tcp_v6_syn_recv_sock()

This commit fixes a race condition where a child socket is inserted into
the TCP ehash table before its IPv6-specific fields are fully initialized.
It introduces an opt_child_init callback in the syn_recv_sock af_ops to
allow IPv6 mapped sockets to be initialized before hash insertion.

Link: https://lore.kernel.org/netdev/69949275.050a0220.2eeac1.0145.GAE@google.com/
Link: https://patch.msgid.link/20260217161205.2079883-1-edumazet@google.com

> diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connection_sock.h
> index 7649d4901f0c4..3d19420dce511 100644
> --- a/include/net/inet_connection_sock.h
> +++ b/include/net/inet_connection_sock.h
> @@ -42,7 +42,9 @@ struct inet_connection_sock_af_ops {
>  				      struct request_sock *req,
>  				      struct dst_entry *dst,
>  				      struct request_sock *req_unhash,
> -				      bool *own_req);
> +				      bool *own_req,
> +				      void (*opt_child_init)(struct sock *newsk,
> +							     const struct sock *sk));

[Severity: Low]
Does this change break the build for the DCCP subsystem?

It looks like dccp_v4_request_recv_sock(), dccp_v6_request_recv_sock(),
and their caller dccp_check_req() in net/dccp/minisocks.c were not updated
to handle this new 7th argument. This would result in compilation errors
when CONFIG_IP_DCCP is enabled.

[Severity: High]
This isn't a bug introduced by this patch, but does the DCCP subsystem
suffer from the same race condition this commit fixes for TCP?

In net/dccp/ipv6.c:dccp_v6_request_recv_sock(), the child socket is created
and inserted into the ehash table by dccp_v4_request_recv_sock() before
its IPv6-specific fields are initialized:

        newsk = dccp_v4_request_recv_sock(sk, skb, req, dst,
                                          req_unhash, own_req);
        if (newsk == NULL)
                return NULL;

        newdp6 = (struct dccp6_sock *)newsk;
        newinet = inet_sk(newsk);
        newinet->pinet6 = &newdp6->inet6;

Could concurrent threads access uninitialized IPv6 fields via a lookup,
similar to the syzbot crash found in TCP?

[ ... ]

> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index 753a881ce3cdf..ec3b0aa0a6260 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -1565,6 +1567,10 @@ struct sock *tcp_v4_syn_recv_sock(const struct sock *sk, struct sk_buff *skb,
>  	}
>  	sk_setup_caps(newsk, dst);
>  
> +#if IS_ENABLED(CONFIG_IPV6)
> +	if (opt_child_init)
> +		opt_child_init(newsk, sk);
> +#endif
>  	tcp_ca_openreq_child(newsk, dst);

[Severity: Critical]
This is a pre-existing issue, but does this routing failure path in
tcp_v4_syn_recv_sock() cause a use-after-free of the listener's IPv6
options?

Just above this block in tcp_v4_syn_recv_sock():

        if (!dst) {
                dst = inet_csk_route_child_sock(sk, newsk, req);
                if (!dst)
                        goto put_and_exit;
        }

If inet_csk_route_child_sock() fails, the code jumps to put_and_exit and
destroys the child socket. Because opt_child_init() hasn't run yet,
newinet->pinet6 still points to the listener's ipv6_pinfo. The child's
destructor (inet6_destroy_sock) will then free the listener's options,
corrupting the active listener socket.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903000029.3508006-3-florian.fainelli@broadcom.com?part=1