From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D5A7136894D for ; Mon, 24 Aug 2026 03:34:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787542494; cv=none; b=W+DNTAJzrUYY+buR9pEzWc6+D1B3l72hqM03ct4BTiw1pzqBZ5SJ3YiAQwPktUmMjaJ0p6OWkpF5cOWiPlk6tBFspZLv2tm3u+6wc8vvMyW8VYUw1s7392ivOa8oRXZF3gSnSgfu/FLSCYQtaoqv3eWuHtKEjQLJIP3SZ3Etbx0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787542494; c=relaxed/simple; bh=tXbprwIsw4+TnWQEjWhGgnauvC05A6g8kXeB1lZBCK0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qNLHj7hAQIerGYgqk3kDxmPRIkEQjKa+j40Cbm6b1Ud/sWi6V7JM4kyMfNGjI8Xk/YNIDOsUMczIyUOz5IOaC3KTScpXU4JSdnAQQTqwabAHSZ09+udQWytqX5KpRrz9DhTSIcmPOwQK+z1riAqKQishOOQkJC4pLwWUis88/vY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=G5rp0jFo; arc=none smtp.client-ip=209.85.214.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="G5rp0jFo" Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-2cc891373e0so32406185ad.2 for ; Sun, 23 Aug 2026 20:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787542492; x=1788147292; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=1ZjZkSQf+Zktufc09rNjCOpfzvoTH5+6Bb0FnK3Vps4=; b=G5rp0jFoCjnG4bg8/dOC+KBVRCWYOQxDWcKFKxH5EWfeg4ji9GHoKUNNNE07W/LluB qD+MvkprQQmp083+qbwWLN51UAwGVaqXaQmw5rMa+LkI9E9Op1CETnumK1pOopshgyuf wROyb0ZdZzzBwGNxvAKpFJqLwD4yy0STfJalC1eNYOpwPeYn4Vbq3gVjt3R8SNSJsCox wgmTfY4lpPhenREZIJTCTBfJRqRb/xDVKKA5lzPs2iBtbXf2RgL/fb6VEdJhIeWDznWk lF85YvoIlfPjs4BVLHB7bvNICwpLeWEQstmdtzsVU71wvzyRdIvyjEoUOP7yt8A3Iqq1 HybA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787542492; x=1788147292; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=1ZjZkSQf+Zktufc09rNjCOpfzvoTH5+6Bb0FnK3Vps4=; b=RrkTRUoAd09dW2sf10+DnjcBI6ppbF6BC8EDIv9LbJOK3hgnHelY+sH7/vxTmGk6rR UE+RtRETboGJ1N6MZI63gf61bVO1acaBZN4/dIZ6RukRdkPoumbWKsVBIeDWrFtZNI8P 97s9Yv1WlOmum6oKHQpkF0DXQr/KWTwqNrsT3hNus5nbPEzSbGxTcTjbRecEwfKUYHwW 9ayrjeB0e0Rcm3UCGogjuMtJZnoHXZiWtbVUp9piCp/TRB0yzevb8SXpqNTrfaJcP3T7 P5KM5RYsjqYZh7m+XvPi3CTMw/gfeBfOzKgTA7ZJaKoyh7R3BXAFUvfo5KxQcxiKJk/c 1rEg== X-Forwarded-Encrypted: i=1; AHgh+RoXKuYSfLEYpstT6nUby4i24oLfaPbDXlzgFu4TSKMG4WMOGM8Og++O7J/fji+QFkWDuwaB+mxZeT7amTI=@vger.kernel.org X-Gm-Message-State: AFuF++lh9K1JthBvJwXmmKdSouStJlkC0E8bYW026DlJ6t+lFBdbNsGj N+S3TXzm3AjCfdzpOM9SpYheXDmrqIbD151w01B2lBmMZvfE/mnPReqS X-Gm-Gg: AR+sD12iHx/GV2lHdhV65tzLObH68pucZyHk8IQmI3xJjSKdaCwctnvlQIpDMG7rL76 CKpv6oo9FjUGfH5VyXxRJlMQ5eWNRySWVjVVOQ2uPbP2eERkSpOpku6BVVCt7uXV/YpFqjGESRM fBAg3oavFbxWT3UjD7Ep7qhXgu+xW+ViXrbAE9Ez+SS1lSX1HPCEjSqafVz0IO3R9KHqqe85KhW swGiHw4PJ/BPYqnnPWuw7Z0eSdzyJ4athi2KgIdljvcoW/2v8J9tz5IAfHBoQGFtwIG1AbAN7ns ndYFjWjiEpPXwS5Zg4m6yMFUTk5JhMSmNJGMvEKDBpeUMuF/bk6YYbb7EOhxdFFsD/Jd191Mk2f fTWUSsXoHhydJZtvsTVSd2F+Dln7Co0t2bqmYY8NI7b9Ja33NAZPm74Dl471Wrbof3iA2unCFFp GouRC24PawRkJQAe9XBVOP+kuC85gM6mrNfNOu36eKRy2vR6bH3JlR2KWhe4LDm47B74kViBHcc Q+1URCFpac= X-Received: by 2002:a17:90b:4ac6:b0:38f:18f9:785 with SMTP id 98e67ed59e1d1-395df13ced5mr26345382a91.8.1787542492202; Sun, 23 Aug 2026 20:34:52 -0700 (PDT) Received: from v4bel.. ([58.123.110.97]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-395c8fd34d9sm4227256a91.1.2026.08.23.20.34.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Aug 2026 20:34:51 -0700 (PDT) From: Hyunwoo Kim To: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, ncardwell@google.com, dsahern@kernel.org, idosch@nvidia.com, kuniyu@google.com, horms@kernel.org, willemb@google.com, andrew+netdev@lunn.ch, kees@kernel.org, jiayuan.chen@linux.dev Cc: kerneljasonxing@gmail.com, ij@kernel.org, martin.lau@kernel.org, shakeel.butt@linux.dev, matttbe@kernel.org, martineau@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, imv4bel@gmail.com, stable@vger.kernel.org Subject: [PATCH net v2 8/8] tcp: do not inherit retransmit state from parent Date: Mon, 24 Aug 2026 12:32:52 +0900 Message-ID: <20260824033331.1084971-9-imv4bel@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260824033331.1084971-1-imv4bel@gmail.com> References: <20260824033331.1084971-1-imv4bel@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit A child gets a copy of the parent's retransmit state when it is cloned. On a listener it is all zero, which is why commit eb2c80ca87b1 ("tcp: do not clear packets_out in tcp_create_openreq_child()") and commit 5c701549c9a6 ("tcp: move retrans_out, sacked_out, tlp_high_seq, last_oow_ack_time init to tcp_disconnect()") dropped the initialization of packets_out, retrans_out and sacked_out here. lost_out, retransmit_skb_hint and highest_sack have never been cleared here. The parent can morph from listener to active session while a request is still being processed, and connect(AF_UNSPEC) followed by connect() gets it there. tcp_check_req() does not hold the listener lock, so nothing pins the parent's state between the TCP_LISTEN test and the clone. The child then copies the counters and the two pointers into the parent's retransmit queue. sk_clone() sets sk_send_head to NULL, and tcp_rtx_queue is unioned with it, so the child's retransmit queue is empty. That does not help. packets_out is set again as soon as the child sends anything, and tcp_xmit_retransmit_queue() picks the copied hint over the queue head. When the parent disconnects, tcp_write_queue_purge() frees those skbs, but the pointers the child copied are left alone. The child then gets an ACK, enters the retransmit path and writes into a freed skb. In short: socket(AF_INET) -> setsockopt(TCP_DEFER_ACCEPT, 30) -> bind -> listen // a client connects and sends one byte. the kernel processes // that segment while the steps below run connect(AF_UNSPEC) // stop listening connect(peer) // become an active session send() repeatedly // lower IP_TTL so the peer's IP_MINTTL // drops most of them, and let one // through to get a SACK // parent: packets_out 6, sacked_out 1, lost_out 5, retrans_out 1 // retransmit_skb_hint points at an skb in the parent's queue // the leftover request completes and copies this state connect(AF_UNSPEC) // those skbs are freed listen() // or the child is dropped accept() // the child sends data, one segment is lost, and the ACK that // comes back takes the retransmit path to the copied hint KASAN log: BUG: KASAN: slab-use-after-free in __pskb_trim_head+0x66b/0x900 Write of size 16 at addr ffff888008141530 by task repro/76 ... Call Trace: __pskb_trim_head+0x66b/0x900 tcp_trim_head+0x69/0x540 __tcp_retransmit_skb+0x14e/0x26b0 tcp_retransmit_skb+0x1b/0x250 tcp_xmit_retransmit_queue.part.0+0x3b1/0x970 tcp_ack+0x3382/0x7430 tcp_rcv_established+0x631/0x3a00 tcp_v4_do_rcv+0x449/0x960 __release_sock+0x1f2/0x2a0 release_sock+0x176/0x1d0 tcp_sendmsg+0x30/0x40 __sys_sendto+0x316/0x380 __x64_sys_sendto+0xdb/0x1b0 ... Allocated by task 76: __alloc_skb+0x11e/0x890 tcp_stream_alloc_skb+0x2c/0x5c0 tcp_sendmsg_locked+0x1377/0x3df0 tcp_sendmsg+0x26/0x40 __sys_sendto+0x316/0x380 ... Freed by task 80: skb_release_data+0x554/0x810 __kfree_skb+0x42/0x60 tcp_write_queue_purge+0x6ef/0xf40 tcp_disconnect+0x2fc/0x1e10 __inet_stream_connect+0x6d0/0xdf0 inet_stream_connect+0x52/0xa0 __sys_connect+0xfc/0x130 ... The buggy address belongs to the object at ffff888008141380 which belongs to the cache skbuff_small_head of size 704 We need to make sure this can not happen, by clearing them after socket cloning. A listener always has them zero, so an ordinary passive open is not affected. Clearing only the pointers is not enough: the counters would then describe a retransmit queue the child does not have, and tcp_fastretrans_alert() and tcp_retransmit_timer() warn. Very similar to commit 8b485ce69876 ("tcp: do not inherit fastopen_req from parent") Fixes: 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim --- net/ipv4/tcp_minisocks.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c index 7fe318d9e0aed2..2fde196dd302f5 100644 --- a/net/ipv4/tcp_minisocks.c +++ b/net/ipv4/tcp_minisocks.c @@ -660,6 +660,12 @@ struct sock *tcp_create_openreq_child(const struct sock *sk, tcp_ecn_openreq_child(newsk, req, skb); newtp->fastopen_req = NULL; RCU_INIT_POINTER(newtp->fastopen_rsk, NULL); + newtp->packets_out = 0; + newtp->retrans_out = 0; + newtp->sacked_out = 0; + newtp->lost_out = 0; + newtp->retransmit_skb_hint = NULL; + newtp->highest_sack = NULL; newtp->bpf_chg_cc_inprogress = 0; tcp_bpf_clone(sk, newsk); -- 2.43.0