Netdev List
 help / color / mirror / Atom feed
From: Hyunwoo Kim <imv4bel@gmail.com>
To: Eric Dumazet <edumazet@google.com>
Cc: ncardwell@google.com, kuniyu@google.com, davem@davemloft.net,
	kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
	willemb@google.com, fmancera@suse.de, netdev@vger.kernel.org,
	imv4bel@gmail.com
Subject: Re: [PATCH net] tcp: fix use-after-free of the listener's ipv6_pinfo after IPV6_ADDRFORM
Date: Wed, 12 Aug 2026 08:34:38 +0900	[thread overview]
Message-ID: <anuxjgodjdFrD9Ud@v4bel> (raw)
In-Reply-To: <CANn89iLN3DVs_SRrY1R7Eh1oZsSQqrgZdFSaaV3weCX3aFeR4g@mail.gmail.com>

On Tue, Aug 11, 2026 at 08:57:12PM +0200, Eric Dumazet wrote:
> On Tue, Aug 11, 2026 at 8:37 PM Hyunwoo Kim <imv4bel@gmail.com> wrote:
> >
> > IPV6_ADDRFORM moves an established AF_INET6 TCP socket over to tcp_prot
> > and ipv4_specific. The socket is still a tcp6_sock though, so ->pinet6
> > keeps pointing at the ipv6_pinfo inside it and sk_destruct stays the IPv6
> > one; commit d38afeec26ed ("tcp/udp: Call inet6_destroy_sock() in IPv6
> > sk->sk_destruct().") relies on that to release the IPv6 state.
> >
> > Once such a socket is disconnected and listen()ed again, its children are
> > cloned from an IPv6 parent but allocated from tcp_prot, so they have no
> > ipv6_pinfo of their own and inherit the listener's ->pinet6 and its IPv6
> > destructor. The only thing that would fix that up is
> > tcp_v6_mapped_child_init(), which is not passed to tcp_v4_syn_recv_sock()
> > on this path. A child accepted from such a listener can outlive it, and
> > its destructor then runs inet6_cleanup_sock() on the freed listener.
> >
> > Commit 858d2a4f67ff ("tcp: fix potential race in tcp_v6_syn_recv_sock()")
> > added opt_child_init for the v4-mapped child; this is the same stale
> > ->pinet6 on the path that never gets it.
> >
> > Clear the IPv6 fields on the child. The converted listener has to keep
> > its own, so there is nothing to clear on the IPV6_ADDRFORM side.
> >
> > Fixes: d38afeec26ed ("tcp/udp: Call inet6_destroy_sock() in IPv6 sk->sk_destruct().")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
> > ---
> >  net/ipv4/tcp_ipv4.c | 6 +++++-
> >  net/ipv6/af_inet6.c | 3 +++
> >  2 files changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> > index 7f413f509d7dce..f830b212d38e49 100644
> > --- a/net/ipv4/tcp_ipv4.c
> > +++ b/net/ipv4/tcp_ipv4.c
> > @@ -1730,8 +1730,12 @@ 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)
> > +       if (opt_child_init) {
> >                 opt_child_init(newsk, sk);
> > +       } else {
> > +               newinet->pinet6 = NULL;
> > +               newinet->ipv6_fl_list = NULL;
> 
> Instead of adding a new test in inet6_cleanup_sock(() I would add here :
> 
> newsk->sk_destruct = inet_sock_destruct;
> 
> 
> 
> > +       }
> >  #endif
> >         tcp_ca_openreq_child(newsk, dst);
> >
> > diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
> > index 282912a1199992..2090289408c035 100644
> > --- a/net/ipv6/af_inet6.c
> > +++ b/net/ipv6/af_inet6.c
> > @@ -479,6 +479,9 @@ void inet6_cleanup_sock(struct sock *sk)
> >         struct sk_buff *skb;
> >         struct ipv6_txoptions *opt;
> >
> > +       if (!np)
> > +               return;
> > +
> >         /* Release rx options */
> >
> >         skb = xchg(&np->pktoptions, NULL);
> > --
> > 2.43.0
> 
> 
> Also, it seems weird that all these issues caused by tcp_disconnect()
> are fixed by AI agents adding code in TCP fast paths.
> 
> What about adding code in tcp_disconnect() that only fuzzers are possibly using?
> 
> Untested patch:
> 
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 455441f1b694904172cfa1d8e7bac7076b60cb24..9dd44b0a31c4dc751b22558dc6b53ed49598e0b6
> 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -3501,6 +3501,15 @@ int tcp_disconnect(struct sock *sk, int flags)
>                 sk->sk_frag.page = NULL;
>                 sk->sk_frag.offset = 0;
>         }
> +
> +#if IS_ENABLED(CONFIG_IPV6)
> +       if (sk->sk_family == PF_INET &&
> +           sk->sk_destruct == inet6_sock_destruct) {

I tested this, and it does not work when tcp_v6_init_sock() has installed
tcp6_destruct_sock.

static int tcp_v6_init_sock(struct sock *sk)
{

#if defined(CONFIG_TCP_MD5SIG) || defined(CONFIG_TCP_AO)
        tcp_sk(sk)->af_specific = &tcp_sock_ipv6_specific;
        sk->sk_destruct = tcp6_destruct_sock;
#endif

}

What about "if (sk->sk_family == PF_INET && inet->pinet6)" ?

> +               sk->sk_destruct = inet_sock_destruct;

IIRC overwriting sk_destruct here breaks things like ULPs? Not verified.

> +               inet->pinet6 = NULL;
> +       }
> +#endif
> +
>         sk_error_report(sk);
>         return 0;
>  }

If sk_destruct is left alone the NULL check has to stay, so:

diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 455441f1b69490..bbdd5b08593061 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3501,6 +3501,14 @@ int tcp_disconnect(struct sock *sk, int flags)
                sk->sk_frag.page = NULL;
                sk->sk_frag.offset = 0;
        }
+
+#if IS_ENABLED(CONFIG_IPV6)
+       if (sk->sk_family == PF_INET && inet->pinet6) {
+               inet->pinet6 = NULL;
+               inet->ipv6_fl_list = NULL;
+       }
+#endif
+
        sk_error_report(sk);
        return 0;
 }
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 282912a1199992..2090289408c035 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -479,6 +479,9 @@ void inet6_cleanup_sock(struct sock *sk)
        struct sk_buff *skb;
        struct ipv6_txoptions *opt;

+       if (!np)
+               return;
+
        /* Release rx options */

        skb = xchg(&np->pktoptions, NULL);

      reply	other threads:[~2026-08-11 23:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-11 18:37 [PATCH net] tcp: fix use-after-free of the listener's ipv6_pinfo after IPV6_ADDRFORM Hyunwoo Kim
2026-08-11 18:57 ` Eric Dumazet
2026-08-11 23:34   ` Hyunwoo Kim [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=anuxjgodjdFrD9Ud@v4bel \
    --to=imv4bel@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fmancera@suse.de \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=kuniyu@google.com \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=willemb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox