From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from va-2-26.ptr.blmpb.com (va-2-26.ptr.blmpb.com [209.127.231.26]) (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 E87243FD121 for ; Thu, 3 Sep 2026 07:07:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.127.231.26 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788419247; cv=none; b=WbRYacyQoHYmDBjRHtqawzVe9n1/TWyawRxbYmMN2IAZj5VTUMAzQ7yngEvuM9uU+hDRndnssnV5JbKxzym12sGByuhJrVxbcdRuyHa3Jd140OuSbThFpfgdjSvMbMB37Q5iyyuCwodGAg+FUSSg7p+cg4YvC7j+IXrk29ch4vw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788419247; c=relaxed/simple; bh=A66lK2xgR6dgfhgpP3WmxHBoNqb2x57ZYFpl0mrYpDs=; h=To:Message-Id:References:Cc:Subject:In-Reply-To:From:Mime-Version: Date:Content-Type; b=luiRWQ/YcM5q5Hjx2+adIiR2Bmmywctl8vbbxyhDcTw4Jm3Ee+bfI0btf2O2hohBubRKx9cJ24Yq2WlfjlwZQwoy5QF8bkEAG2EYA2SHMjacoaVFuwnoAgLyo6PVTmBQWFNIkw524amyFmnjoUixyrWxFL+xSKm/MIaIl7uo5DY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=moonshot.ai; spf=pass smtp.mailfrom=moonshot.ai; dkim=pass (2048-bit key) header.d=moonshot.ai header.i=@moonshot.ai header.b=bCYV5bVb; arc=none smtp.client-ip=209.127.231.26 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=moonshot.ai Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=moonshot.ai Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=moonshot.ai header.i=@moonshot.ai header.b="bCYV5bVb" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=feishu2510091218; d=moonshot.ai; t=1788419234; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=2QefUN6DKjkvMaj8sGNZPNqaHqeihTj8Tk74loUgYs8=; b=bCYV5bVbvtChYjw+quUYde9aVA4D3ExGS+h4bxh+0xhgI8wjUosP5VK+tPwu7Z6eL9gTCa HSDDfIYJ72KQ8s00hJaJTnhMbpA3I165i0rxlH2zS93Qdn7DgIhcI3lhDsyMJAwRtYZqV6 lsxDJxbopuPa9aN7X03RiEXrzQ2SpTOmjkQuZoVQcA3pWhbRMYNKh1/yt5pvwYGRCkGWHW fAllngcQs9F+W8mrM7mqREOEmcrzSLvgO5UYtHF5TXMivh7W5sAsg/H9ivWtjnxNXVc0QV 2V7xu465EToE8YuzctTIWYGdwFsd9iLzI/conTOhSJZunmo2WTHKbbrZuZEWjw== To: "Matthieu Baerts" , "Jiayuan Chen" Message-Id: <20260903070649.3965366-1-yilinzhang@moonshot.ai> X-Mailer: git-send-email 2.34.1 References: Content-Transfer-Encoding: 7bit Cc: "Mat Martineau" , , Subject: Re: [PATCH] tcp: fastopen: check rsk_drop_req() in tcp_fastopen_create_child() In-Reply-To: From: "Yilin Zhang" Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Lms-Return-Path: X-Original-From: Yilin Zhang Date: Thu, 3 Sep 2026 15:06:49 +0800 Received: from dev.msh-dev.svc.cluster.local ([117.157.206.135]) by smtp.feishu.cn with ESMTPS; Thu, 03 Sep 2026 15:07:12 +0800 Content-Type: text/plain; charset=UTF-8 Here is a packetdrill reproducer for the MPTCP subflow/TFO issue. It first obtains a TFO cookie and the server key during an MP_CAPABLE handshake, then sends an MP_JOIN SYN from a new source port with the corresponding token and cookie. The final ACK is intentionally omitted. With the fix, the request remains in the SYN queue: the MPTCP reset is followed by a normal SYN/ACK that echoes the cookie, and the second accept() returns EAGAIN. Without the fix, tcp_fastopen_create_child() ignores drop_req=true after subflow_syn_recv_sock() destroys the cloned child. The TFO path queues that child instead; the SYN/ACK omits the cookie, and closing the listener reports a refcount/use-after-free warning. -- >8 -- gtests/net/mptcp/fastopen/server-tfo-mpjoin-syn_v4.pkt -- >8 -- // Regression test: an MP_JOIN SYN with a valid TFO cookie must not queue // a destroyed child. --tolerance_usecs=100000 `../common/defaults.sh` // MPTCP listener with server-side Fast Open enabled. +0.0 socket(..., SOCK_STREAM, IPPROTO_MPTCP) = 3 +0.0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0.0 setsockopt(3, SOL_TCP, TCP_FASTOPEN, [2], 4) = 0 +0.0 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) +0.0 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 +0.0 bind(3, ..., ...) = 0 +0.0 listen(3, 1) = 0 // Obtain a TFO cookie and learn the server key. +0.1 < S 0:0(0) win 65535 +0.0 > S. 0:0(0) ack 1 +0.2 < . 1:1(0) ack 1 win 450 < mpcapable v1 flags[flag_h] key[ckey=2, skey]> +0.0 accept(3, ..., ...) = 4 // Use a new source port with the same address; the cookie remains valid. +0.1 < 192.0.2.1:15000 > 192.168.0.1:8080 S 0:0(0) win 65535 // The fatal MPTCP fallback destroys the cloned child and resets the flow. +0.0 > 192.168.0.1:8080 > 192.0.2.1:15000 R. 0:0(0) ack 1 // Normal SYN processing sends a SYN/ACK and echoes the TFO cookie. +0.0 > 192.168.0.1:8080 > 192.0.2.1:15000 S. 0:0(0) ack 1 // Without the final ACK, the request must remain in the SYN queue. +0.2 accept(3, ..., ...) = -1 EAGAIN (Resource temporarily unavailable) -- >8 -- For the MPTCP packetdrill fork, save this as `gtests/net/mptcp/fastopen/server-tfo-mpjoin-syn_v4.pkt` and run it with that fork's packetdrill binary. Tested on Linux 7.3.0-rc1 (defconfig + MPTCP + KASAN, QEMU guest): the unpatched kernel sends a SYN/ACK without the TFO cookie and reports `refcount_t: underflow; use-after-free` when the listener closes; the fixed kernel passes, with the second `accept()` returning EAGAIN.