Re: [PATCH net 3/3] tcp: do not inherit out_of_order_queue from parent

Hyunwoo Kim <[email protected]>
Newsgroups org.kernel.vger.stable,org.kernel.vger.netdev
Message-ID <aoN8UYf5as4IWCon@v4bel>
On Mon, Aug 17, 2026 at 08:27:32PM +0800, Jiayuan Chen wrote:
> 
> On 8/17/26 5:03 PM, Hyunwoo Kim wrote:
> > A child gets a copy of the parent's out_of_order_queue, which can be non
> > empty when/if parent morphs from listener to active session. Parent and
> > child then point at the same rbtree.
> > 
> > The parent is no longer a listener, so inet_csk_reqsk_queue_add() forgets
> > the child immediately, and tcp_disconnect() frees the skbs the parent
> > still owns. The parent's own root and ooo_last_skb are left alone, so it
> > keeps using those skbs. That is a use-after-free, and the parent frees
> > them a second time when it closes.
> > 
> > We need to make sure this can not happen, by initializing the queue after
> > socket cloning.
> > 
> > Very similar to commit 8b485ce69876 ("tcp: do not inherit fastopen_req
> > from parent")
> > 
> > Fixes: 9f5afeae5152 ("tcp: use an RB tree for ooo receive queue")
> > Cc: [email protected]
> > Signed-off-by: Hyunwoo Kim <[email protected]>
> > ---
> >   net/ipv4/tcp_minisocks.c | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
> > index 6ab3e3a0b43173..d13813d50947dd 100644
> > --- a/net/ipv4/tcp_minisocks.c
> > +++ b/net/ipv4/tcp_minisocks.c
> > @@ -591,6 +591,7 @@ struct sock *tcp_create_openreq_child(const struct sock *sk,
> >   	newtp->total_retrans = req->num_retrans;
> >   	tcp_init_xmit_timers(newsk);
> > +	newtp->out_of_order_queue = RB_ROOT;
> 
> 
> Does tcp_rtx_queue suffer from the same issue?

No, sk_clone() already clears it:

	sock_copy(newsk, sk);
	[...]
	newsk->sk_send_head	= NULL;    // tcp_rtx_queue

I also checked this at runtime, and the child's rtx queue was always
empty even when the parent's was not.


Best regards,
Hyunwoo Kim
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.