Re: [PATCH stable 5.15.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 7th argument (`opt_child_init`) to the `syn_recv_sock` function pointer in `struct inet_connection_sock_af_ops`, but completely fails to update the DCCP subsystem. This breaks the build for DCCP.

Pre-existing issues:
- [Critical] This problem wasn't introduced by this patch, but if route lookup fails when creating an IPv4-mapped IPv6 child socket, the listener's IPv6 resources are erroneously freed.
- [High] This problem wasn't introduced by this patch, but the exact race condition fixed by this patch in TCP is also present in DCCP's IPv6-mapped implementation, which remains unfixed.
--

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

tcp: fix potential race in tcp_v6_syn_recv_sock()

This commit addresses a race condition in tcp_v6_syn_recv_sock() where the
child socket is visible in the TCP ehash table before its ipv6_pinfo is
fully initialized. It moves the initialization code into a new helper
tcp_v6_mapped_child_init() and passes it to tcp_v4_syn_recv_sock() to run
before ehash 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 7a015055fe6db..97e8969b37967 100644
> --- a/include/net/inet_connection_sock.h
> +++ b/include/net/inet_connection_sock.h
[ ... ]
> @@ -41,7 +41,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 DCCP? The patch adds the opt_child_init
argument to the syn_recv_sock function pointer, but does not appear to
update the DCCP subsystem. Calling syn_recv_sock with 6 arguments in
net/dccp/minisocks.c:dccp_check_req(), and defining
dccp_v4_request_recv_sock() and dccp_v6_request_recv_sock() without the 7th
argument will likely cause compiler errors.

[Severity: High]
This is a pre-existing issue, but does the same race condition you fixed
here in TCP also affect DCCP?

In net/dccp/ipv6.c:dccp_v6_request_recv_sock(), the IPv6 fields for mapped
sockets are initialized after the socket is already created and inserted
into the ehash by dccp_v4_request_recv_sock():

    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;

This appears to leave pinet6 pointing to the listener while the child socket
is already visible to other CPUs, exposing the same race.

[ ... ]
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index f7693166c5161..32b55a6b5e033 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
[ ... ]
> @@ -1612,6 +1614,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

[Severity: Critical]
This is a pre-existing issue, but can this lead to freeing the listener's
IPv6 resources if route lookup fails?

If inet_csk_route_child_sock() fails before opt_child_init() is called
in tcp_v4_syn_recv_sock():

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

It jumps directly to the put_and_exit label where tcp_done(newsk) is called
to destroy the child socket. Since pinet6 has not yet been reassigned by
opt_child_init(), it still points to the listener's ipv6_pinfo. This appears
to incorrectly free the listener's resources, such as pktoptions and rxpmtu,
which could lead to a double-free or use-after-free on the listener.

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