From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) (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 C32953AC0C9 for ; Thu, 9 Jul 2026 19:19:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783624785; cv=none; b=Ip6eNCqngsfpEpvYkqsEKeQQHK3O4eQ5YzkO6fLYwMz7aCeNpylvGmVPs3CmbDJl4QaQ9g94M0yVK/nsrERfvUKoDzvRvwHa2kiU+Kb6SlAllo+Q6XPTuHIjRMlXD9h3kKSTz1axkCDio/Fm54b02BAhCDkcKzk/GnU22IkyKUU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783624785; c=relaxed/simple; bh=ag2iaJNRSatXfZcIQOXwJLWZ7MP77+wFc5guU6LKKE4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=a0CnNuJtWkqV6WXdRQyW7gcx3tmK5riFarcsr64tj1xZUh/1eNMg8AykkKSOCPzX9lBxzAdygWFgtPVx8RFOx4DmFpKsuaOuhUks9XMBs3UmMTnAVa+b8WNVWI1wl5nYnSRBFiRko2Rum4/1E9NjpgGhC1IIDLeyB08qoQkroEg= 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=PHrs6MxO; arc=none smtp.client-ip=209.85.222.180 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="PHrs6MxO" Received: by mail-qk1-f180.google.com with SMTP id af79cd13be357-92e57a753f9so10109885a.2 for ; Thu, 09 Jul 2026 12:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783624783; x=1784229583; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=8lTAkLkaFfueQ/1V07Pbb9gud8KYPki4tliZP1BPO3s=; b=PHrs6MxO1ELbyBow0rxKOskrO9vH7JuuPzlu+5FRPCzFOQA65F2pza394Wetas0dTP 7zwcIAHBmAbooaocKM1TznSzTYCEmGJKxDId3kgIwtg5UYzPPR6TIx7Lf7zgHKCvvhzf 31lvh6xDtSyXnVvrWCQd2m3kq5V5RvV08OhRtLksDuZh36kWClGxf//OWSz+Pgx0DOHN DqrTd473rwe5maDyGq4bgBo96+CCf8SqWWog2ejisq6P/9d2a9VT9QzZ9ygUXyldosJK iSh15opyzZ9LsNxMzbOHifuSM1Ne2+O+xLuuzn5baf90zYqQ8F61TNDI6+VVP1XjVWgO y3aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783624783; x=1784229583; h=content-transfer-encoding:mime-version: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=8lTAkLkaFfueQ/1V07Pbb9gud8KYPki4tliZP1BPO3s=; b=JTcz4t76Oew+CFUbo9KYbAjxq0cxrIMYxb6CuKyxZ8EF8MYd0ydB2tzRTgt+Hy1lbi izukueFN+08hEm1iRrRRJ5zlkCAH4mif5eShlgaVujUjc8ra6eQFeznduyZdKD6oiAoz /XiUA8eRiYqIaguiyTGwXIOcO359doDmIHx+Om/urULWnhcqIA2C/NK9mfJMEKwQcjLE tIvyibxfzXj4Ip5c/IwkDXMzRwuiLY/acFn4CRyMv3V2P88gL1XDGyTabnlpZYEQIIV3 rIC4xGsWTTXK6S10d1/p+oEuP7OC0+1tZgMnvAQnnNHrwBEu93+tBFm3hTo7d4uRruR+ D+rw== X-Forwarded-Encrypted: i=1; AHgh+RoNRIup38VUBlHvo1lRbCLZC+FS0iU7fCCebUHgr+NAt3Vv+EylyRK3/bd2INuWLc/dFyECrvFxk7KDSrM=@vger.kernel.org X-Gm-Message-State: AOJu0YyfYZL5FR55h3HJA21YGXkf+NSmC4Jcmbnl2gf/+Io2u4kwBz5F wjjmstfTyBsyML7QmuObgp7eefccSR7u36R7x2PbPUSX2EcE6gEuqDI2 X-Gm-Gg: AfdE7cmIv8nL7EXmv/zBYEVOqN+NHtKvvSKw1+E5NpiSbJjEKZ13g0+dJzltXmO80rE EPe/2PWZHGD0BmDnWymPp3S28i+Albs4vu5nF1mKjtTnKjebL5/6oSxSMYAYl37L7OzJxmug6rc fxevrqZ55aSPNqG8EtncJGbonBsVKXqcc9OuhCVX4K4CYVUbron0oF9hbIbcB1UOiuVVE6HpPNK 49Zx87Bp7BgmvZulsHSSU9bFl+Gv97JoVFGih/ngGikzYQZBxvivoj4Bip4bNXDfIZILRMqGM/n D6IMOGeAgsdRM+gD8zOiAaQu0PunubqSlrqEEYi8bzbTrxyUv6A8kZEv7dw65S7K4F3yrfNpnDu WM7WtDJFjOaazBNte0kkr67ZNW3rP+2J19CFKruZIy6dqpGq1zJL9zidfa9vfiq19B1C/R0jJJB wKek8OwOm5Hx1lcyW3WxDklJgGElvloFpgV9GQafCeppnLJuS3MSRQQ2wua5Y8MmhFGZV6KjvJb Iq4GNysDQdMousiCLAZNLEQ96skwi5m X-Received: by 2002:a05:6214:c87:b0:8fe:49d6:fb76 with SMTP id 6a1803df08f44-8fec3810ff7mr93576996d6.57.1783624782634; Thu, 09 Jul 2026 12:19:42 -0700 (PDT) Received: from server0.tail6e7dd.ts.net (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8ffd87c8d4csm25507836d6.44.2026.07.09.12.19.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jul 2026 12:19:42 -0700 (PDT) From: Michael Bommarito To: Matthieu Baerts , Mat Martineau Cc: Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Gang Yan , mptcp@lists.linux.dev, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH net v3] mptcp: only set DATA_FIN when a mapping is present Date: Thu, 9 Jul 2026 15:19:25 -0400 Message-ID: <20260709191925.2811195-1-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit mptcp_get_options() clears only the status group of struct mptcp_options_received; data_seq, subflow_seq and data_len are filled in by mptcp_parse_option() exclusively inside the DSS mapping block, which runs only when the DSS M (mapping present) bit is set. A peer can send a DSS option with the DATA_FIN flag set but the mapping bit clear. The parser then records mp_opt->data_fin while leaving data_len and data_seq uninitialized. For a zero-length segment mptcp_incoming_options() evaluates if (mp_opt.data_fin && mp_opt.data_len == 1 && mptcp_update_rcv_data_fin(msk, mp_opt.data_seq, mp_opt.dsn64)) which reads the uninitialized data_len and data_seq; KMSAN reports an uninit-value in mptcp_incoming_options(). The stale data_seq can also be fed into the receive-side DATA_FIN sequence tracking. Record the DATA_FIN flag only when the DSS option carries a mapping, so data_fin is never set without data_seq and data_len also being present. data_fin is part of the status group that mptcp_get_options() clears up front, so on the no-map path it stays zero and the zero-length DATA_FIN branch is simply skipped. A DATA_FIN is always transmitted together with a mapping (mptcp_write_data_fin() sets use_map along with data_seq and data_len), so legitimate DATA_FIN handling is unaffected. Move the pr_debug() that logs the parsed DSS flags below the mapping block, so it reports the final data_fin value instead of the stale one it would otherwise print before the assignment. Fixes: 43b54c6ee382 ("mptcp: Use full MPTCP-level disconnect state machine") Suggested-by: Paolo Abeni Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito --- v3: - Move the pr_debug() DSS flag log below the mapping block so it prints the final data_fin value (Gang Yan). data_fin is now assigned only inside the use_map block, so logging it earlier would report a stale value. No functional change to the fix. v2: adopt Paolo Abeni's suggested approach - do not set mp_opt->data_fin at all unless a mapping is present, rather than gating the consumer in mptcp_incoming_options() (v1). data_fin then defaults to the value mptcp_get_options() already clears it to (0) on the no-map path, so the uninitialized data_len/data_seq are never read. Link to v1: https://lore.kernel.org/all/20260617215725.1116295-1-michael.bommarito@gmail.com/ Link to v2: https://lore.kernel.org/all/20260707171730.2679013-1-michael.bommarito@gmail.com/ net/mptcp/options.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/net/mptcp/options.c b/net/mptcp/options.c index dff3fd5d3b559..1b74ca5b6a595 100644 --- a/net/mptcp/options.c +++ b/net/mptcp/options.c @@ -157,17 +157,11 @@ static void mptcp_parse_option(const struct sk_buff *skb, ptr++; flags = (*ptr++) & MPTCP_DSS_FLAG_MASK; - mp_opt->data_fin = (flags & MPTCP_DSS_DATA_FIN) != 0; mp_opt->dsn64 = (flags & MPTCP_DSS_DSN64) != 0; mp_opt->use_map = (flags & MPTCP_DSS_HAS_MAP) != 0; mp_opt->ack64 = (flags & MPTCP_DSS_ACK64) != 0; mp_opt->use_ack = (flags & MPTCP_DSS_HAS_ACK); - pr_debug("data_fin=%d dsn64=%d use_map=%d ack64=%d use_ack=%d\n", - mp_opt->data_fin, mp_opt->dsn64, - mp_opt->use_map, mp_opt->ack64, - mp_opt->use_ack); - expected_opsize = TCPOLEN_MPTCP_DSS_BASE; if (mp_opt->use_ack) { @@ -178,12 +172,18 @@ static void mptcp_parse_option(const struct sk_buff *skb, } if (mp_opt->use_map) { + mp_opt->data_fin = (flags & MPTCP_DSS_DATA_FIN) != 0; if (mp_opt->dsn64) expected_opsize += TCPOLEN_MPTCP_DSS_MAP64; else expected_opsize += TCPOLEN_MPTCP_DSS_MAP32; } + pr_debug("data_fin=%d dsn64=%d use_map=%d ack64=%d use_ack=%d\n", + mp_opt->data_fin, mp_opt->dsn64, + mp_opt->use_map, mp_opt->ack64, + mp_opt->use_ack); + /* Always parse any csum presence combination, we will enforce * RFC 8684 Section 3.3.0 checks later in subflow_data_ready */ -- 2.53.0