From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=162.62.57.64 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794758278; b=zPbEgsRzW1POW504kFHg4MbGcnLi0AAlWnrkvlwjLmT5QbK6uZtrSOrZ+QBqs5BaPqxj tLr8gJ8T60NmuGpwdCnbYPj7Yc/6QjrZ1f9J1ZQgy02maJaGhRHMMoK0Rz3Nh9NTztIec ozb0K6S0q2oXw0Ph01Xm9BaaNoT0mBBBOurGNodxVLiSzyCyJJqmD6NhjF8UlbUtPlKog 6QQuBuQwYSyUptc11xcdPf3QIFaqT4TpWvIt6F9b488YwsnzoIisIss+eLUR1O1GgIaJy H3XuBWIU5Lh9ZOJFajSmeuC6UKjCvdFjpM9pg+taa9Or5OAnqi67t4em7yMRMnL6+mA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794758278; h=DMARC-Filter:DKIM-Signature:Received:X-QQ-mid:Message-ID: X-QQ-XMAILINFO:X-QQ-XMRINFO:From:To:Cc:Subject:Date:X-OQ-MSGID: X-Mailer:MIME-Version:Content-Transfer-Encoding; bh=0v1zQpwZaYEyKOsC8gR5uRwAge3NFdgyHe9M/NEthDo=; b=oz35Abh4kTrScXWfxgGviqtM07IBBTdBeCAkHS8/xvu+BThIJ8xn1rmPCGnWVcA9XFaw hlTav54XZgZgUWf4bQ9r0tj5oCH7gaCHKNqba7j1hL6taek//3zeuQO4WMb4NMtv59MG6 CbN2lL0hhAGzXvaIFhnuYFtx3KzNYof3wJU/6n1eZGhFgwSAaVgQjA16UzDg1K9/Gy/Im HwdxVA/+X0nWowwMYDYeH3QL4F4V1NlNzMIQPWEZ1PnR8cb10JQNouMnZjUqWmjtrvcqF RddrtXEZ9/QXTHg4Gic4qxjEPJS74Z8MbRr1tbb14MSJNvdszGRHnzT28nJc1Rkv1ew== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=qq.com; spf=pass smtp.mailfrom=qq.com; dkim=pass header.d=qq.com header.i=@qq.com header.a=rsa-sha256 header.s=s201512 header.b=qvHk8tzs; arc=none smtp.remote-ip=162.62.57.64 Received: from out162-62-57-64.mail.qq.com (out162-62-57-64.mail.qq.com [162.62.57.64]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B10C8606A31E for ; Sun, 15 Nov 2026 15:57:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org B10C8606A31E Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=qq.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=qq.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=qq.com header.i=@qq.com header.a=rsa-sha256 header.s=s201512 header.b=qvHk8tzs DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1794758272; bh=0v1zQpwZaYEyKOsC8gR5uRwAge3NFdgyHe9M/NEthDo=; h=From:To:Cc:Subject:Date; b=qvHk8tzs7PQHBEutlNzfpoShDxiaQMtJM195x61TwiUUzO4WmKDkMQ1+kOzxzgWPT JtVn6w0JMOo7zYHc8highZNhR34/YJO6nYWVmTWoqijzkJny3TnS/1pqjUmCST3f0a j73CQWdWUJOI/f+BcdGwF6kmBS5mge/kZRXXdelc= Received: from localhost.localdomain ([2409:8d5c:8f0:65e5:103b:e9c7:571:634c]) by newxmesmtplogicsvrszb51-1.qq.com (NewEsmtp) with SMTP id E701F634; Sun, 15 Nov 2026 23:57:48 +0800 X-QQ-mid: xmsmtpt1794758268tbcjhdllm Message-ID: X-QQ-XMAILINFO: MILSKRzDrLPbjPCGtjdGYX5Gw4l311RgOHiCX7K4CQAmYD6xTJfBmCW1ojFvAI rhP32xDbvZBY6mSVQ+1q5Xg5GI9DJyjH5TNAF7uT/UfcAQIsVd3lZof7bN5o19UKK6SvUj4lB3PD UoR22gmttqonTQf9ewbXORee+yJ6JB1ezBaHwu1HuTYZDgJdnmXEZvZvO3eeUuR1Rsyb9HCzFfIo ueaPihFGBM6dhtVbtcB09QSKTwbR2FMe8hUdpxO9qvEb+2NusahYswUHn1dIoGb1rMBBuw2HF/Ax zeEZ1o3ufCmNlx5O0UKoDSlCGcCIo3w2l2/3cKxBqLqHsDXpk/f5gBWAuVUvIaZo4drJwIoZyKE9 TStkb6wv98tIz8V65WjYG9H/oo3jpxV4Qh9k5oeC/wmjhWPC23TgHRuSS9eK2WhS2zEwHVzz2Kit XgqnT8+lNfyUUyJ40WU5FXJToXRMEYxl2A9ei6bGYAZuJrZQrGhJM9Lq1AI1g58wZ0hhdh3+ULPx oIJD3lPsSi4vA15E2BNc+2a++zbxwOWZFwul5jcS49AO0A1KvCwdcDx4EFs1ZsIli6CUarJ12Zjz h3RwNlKCfJ6dWoPuC0+calfjnn5gK9T2K4UM/8O48tExbcxLCOkYj+UsMH9k6LA+Nd+goqdGGApX HVsGXLkCRgflybKkDRNucPXCqXJL1poLhLBnFeXVTZfJFSFUCrKXd2q0Hu56UWEf85Cut8kZVL2T B0hBecCxmnXnDHo9aExbWkz/dyN3U/N34U1Ax3SAwGYFeE8gGZ5dveQ6hg+4WDDxo9zKXOtoAHXv 7m58zvUThwKtz7zkM4PqXiWYkAjBEOkaov6P4zuQBMFUT/nTHSCKMv6JtQZZ0ICgUoomyh7cNEQ6 sQH03GGoAxdHSrhHBBaob8lAELwyGbdQ/xb939y8qQwvS6TTRv1xnJx2YCBfo1onaOHtkQrnyYeW 5CrwOpz3jeDY/joY+Wqt5ijXcTRKt3BpC8FAV6LbOQBh7nqyOq4X7XY1JiMwYlKrdqPd76sVRMGN RxMCm6p782D1wqPJ0nsXJsQ+XzagGSM30dw6XluboGwBT/jRexdOSZSpez5bWfs3X718CFVZgCs4 oRwVidQbqQagq+eXslVex4b3U9NQinAevA8tlxLp+XyWswIJxIAFgVK3U8xJ4xCs08VfiP X-QQ-XMRINFO: OD9hHCdaPRBwH5bRRRw8tsiH4UAatJqXfg== From: Hang Nan <2122295973@qq.com> To: netdev@vger.kernel.org Cc: mptcp@lists.linux.dev, matttbe@kernel.org, martineau@kernel.org, geliang@kernel.org, davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, kuniyu@google.com, willemb@google.com, linux-kernel@vger.kernel.org, stable@vger.kernel.org, 2122295973@qq.com Subject: [PATCH net v4 0/3] mptcp token hash ordering and token 0 lookups Date: Sun, 15 Nov 2026 23:57:44 +0800 X-OQ-MSGID: <20261115155747.178858-1-2122295973@qq.com> X-Mailer: git-send-email 2.47.3 X-Mailing-List: netdev@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: NanHang <2122295973@qq.com> This series restores acquire ordering for the mptcp token lookup and fixes two pre-existing defects in that hash table which ordering alone cannot cover. Patch 1 converts mptcp_token_get_sock() and mptcp_token_iter_next() to refcount_inc_not_zero_acquire(). These sockets live in a SLAB_TYPESAFE_BY_RCU slab, so the re-check of msk->token and sock_net() after the increment only rejects a recycled socket if those loads are ordered after the increment; without the acquire they can be satisfied before it, against the previous owner's contents. Patch 2 rejects token 0 in mptcp_token_get_sock(). Token 0 is never assigned, but it is what mptcp_token_destroy() stores into a socket being torn down, and what a freshly allocated msk holds until it is hashed. For a lookup for token 0 both validations compare 0 with 0 and accept such a socket; the token is copied from the wire by mptcp_parse_option(), so a peer can ask for it. The join path then uses the result, including msk->pm.anno_list, which is initialised only later. Patch 3 makes mptcp_token_iter_next() re-read the token after the increment and drop the socket unless it is non-zero and still hashes to the slot being walked, so a socket recycled in the same network namespace is not handed to mptcp_diag or the userspace path manager before it is initialised. v1 -> v2: - Point the Fixes: tags at the commits that introduced each lockless lookup instead of at the refcount consolidation (sashiko review). v2 -> v3: - Rewrite the rationale of the ordering patch: the acquire pairs with the SLAB_TYPESAFE_BY_RCU reuse window published by sock_init_data_uid(), not with mptcp_token_destroy() (sashiko review). - Add the token 0 and iterator patches, reported by the same review. v3 -> v4: - Drop "net: core: take the reuseport migration reference with acquire ordering". reuseport_migrate_sock() does not validate anything after the increment, and the listener state that could be raced is re-checked under queue->rskq_lock in inet_csk_reqsk_queue_add(), so the acquire orders nothing there (sashiko review). Hang Nan (3): net: mptcp: take token lookup references with acquire ordering net: mptcp: reject token 0 in mptcp_token_get_sock() net: mptcp: verify the token slot in mptcp_token_iter_next() net/mptcp/token.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) -- 2.47.3