Re: [PATCH net 1/3] ipv6: fix request socket use-after-free after IPV6_ADDRFORM

[Hyunwoo Kim <imv4bel@gmail.com>]

On Mon, Aug 17, 2026 at 08:14:03PM +0800, Jiayuan Chen wrote:
> 
> On 8/17/26 5:03 PM, Hyunwoo Kim wrote:
> > IPV6_ADDRFORM turns an AF_INET6 TCP socket into an AF_INET one. It requires
> > the socket to be established, and a listener can get there with
> > connect(AF_UNSPEC) followed by connect(). Request sockets queued while it
> > was listening are still there: inet_csk_listen_stop() leaves them in the
> > ehash, and their timers only drop them while the socket is not listening,
> > so making it listen again keeps them alive.
> > 
> > A request that arrived over IPv6 was hashed with inet6_ehashfn(). Its child
> > is cloned from the converted socket and hashed with inet_ehashfn(), so it
> > belongs in a different bucket.
> > 
> > inet_ehash_insert() locks the child's bucket, warns about the mismatching
> > hashes, and replaces the request with the child in the request's own bucket
> > anyway. reqsk_queue_unlink() locks the bucket the request is really in, so
> > there is no synchronization between the two. Both can see the request still
> > hashed and both can drop the reference the ehash holds.
> > 
> > The extra put takes the request's refcount to zero too early, so it is
> > freed while it is still on the listener's accept queue. The listener is
> > then closed, and inet_csk_listen_stop() reads the freed request and
> > writes to it in reqsk_put().
> > 
> > Refuse the conversion if inet_csk_reqsk_queue_len() is not zero. Nothing
> > clears that counter when a socket stops listening or listens again, so it
> > still accounts for the requests left in the ehash. A socket that never
> > listened is not affected.
> > 
> > Fixes: 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
> > ---
> >   net/ipv6/ipv6_sockglue.c | 4 ++++
> >   1 file changed, 4 insertions(+)
> > 
> > diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
> > index b4c977434c2e0a..64fc6127e75332 100644
> > --- a/net/ipv6/ipv6_sockglue.c
> > +++ b/net/ipv6/ipv6_sockglue.c
> > @@ -572,6 +572,10 @@ int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
> >   					retv = -EBUSY;
> >   					break;
> >   				}
> > +				if (inet_csk_reqsk_queue_len(sk)) {
> > +					retv = -EBUSY;
> > +					break;
> > +				}
> >   			} else {
> >   				break;
> >   			}
> 
> Just thinking out loud.
> 
> Gating on inet_csk_reqsk_queue_len() reads a bit oddly, since we already
> require TCP_ESTABLISHED right above.

The TCP_ESTABLISHED check is below inet_csk_reqsk_queue_len(), not above it.

> 
> it's really just a proxy for "this socket used to listen and still has
> leftover requests.

Yes. I did it this way on purpose, to avoid touching the fast path.

> 
> The real issue is we should drain req when disconnect the listen socket, 

Doing this at disconnect does not look easy. Since 079096f103fa the requests
only live in the ehash, and there is no list of them attached to the listener.
So the only way to find them is to walk the whole ehash, like inet_twsk_purge()
does, and that walk is currently only done when a netns is destroyed.

> at least we should avoid replaces the request with the child even when
> sk->sk_hash != osk->sk_hash.
> 
> But that's the hot path, so hardening it for such a rare corner case isn't
> worth the cost.

Fixing the root cause properly would look like this:

--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1756,6 +1756,11 @@ struct sock *tcp_v4_syn_recv_sock(...)
 		goto put_and_exit; /* OOM, release back memory */
 #endif

+	/* sk_ehashfn() must agree, or the replace crosses ehash buckets. */
+	if (unlikely(req_unhash &&
+		     newsk->sk_family != req_to_sk(req_unhash)->sk_family))
+		goto put_and_exit;
+
 	if (__inet_inherit_port(sk, newsk) < 0)
 		goto put_and_exit;

That said, the review [1] on the other patch, which is the original of this
class and the more important one, said not to touch the fast path, so I went
with changing setsockopt instead. (If you have time, I would appreciate it if
you could also take a look at that other patch :))

Also, while testing various things, I found that this setsockopt patch can be
bypassed by a race, because qlen is only incremented after the request is
already in the ehash. Fixing that cleanly does not look easy. Trying to address
the root cause indirectly seems to bring in more and more things to take care of.

[1]: https://lore.kernel.org/all/CANn89iLN3DVs_SRrY1R7Eh1oZsSQqrgZdFSaaV3weCX3aFeR4g@mail.gmail.com/


Best regards,
Hyunwoo Kim