From nobody Sun Feb 8 16:05:57 2026 Delivered-To: wpasupplicant.patchew@gmail.com Received: by 2002:ab0:35eb:0:0:0:0:0 with SMTP id w11csp2037058uau; Tue, 21 Jun 2022 10:23:50 -0700 (PDT) X-Google-Smtp-Source: AGRyM1twXwS1tq+dYA+4/WQph77DWf3FyQzfJ9Box00DQkeTZt4dT2fu8koy4S1l6V+U7hT4WuHF X-Received: by 2002:a17:903:2494:b0:168:fee7:6daa with SMTP id p20-20020a170903249400b00168fee76daamr29491139plw.39.1655832229926; Tue, 21 Jun 2022 10:23:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655832229; cv=none; d=google.com; s=arc-20160816; b=A+2wsSM1TjAJSzOmk7FENvq7HnE33hva97HW9hBIDxNhgknN7mU6b08+Qjte9BtD3c SqBPDZIZEYe5YCcYzi6PmZv9Aw3sih09ps4q7rtWNJgzj2DPK8yLUA/YnDxePbdSqvpg VJ5+febnHirwjeBIBp2vCfV8wY8v2ylL4fH11DB5FM7UqgOAhASfopd0abqlEaJKE6kt 9gvzgjQGkssf1slz5xoR9laHwEVfX+n/zW6PXQX8xEyOYv4QTwwh7u+hWmhriWc1AGWp Uu31iKuVD7S8Gh8d228HEnVqYaZxS9h40uM9uEwP4qfenfyOTcUyY3GKS6S8YZGcgVEb ffIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:to:from:dkim-signature; bh=GPoTGIZrq9Vy19X8ghbSXhITg9eMi505n+T6Q/39T1I=; b=m6jd+XlkcmjQycUhUFoBGIdzabSDU5bwupbIL84jYOTG/tKEcVWb+smu8t1W+JdW4T 4XdpNWkglA2we2ZlJuIf2R03yEpSGIjWTc5Gay7s5jAj0FuTZQweANOTDF87hwKRhXTg +syL31VuEiMMPK/jV2f15avQpxJVxpjIeysuvJBjzixaFHJT373K/s+nEHPeCh68pxqr rZXEu4QUt+Oonxor8BpoyAmb5Ki0tbA5MuHK4VePxLR7UYJ0jyevC6IT2cyVByZH0h80 Es84isuITyzC6eQwEGLt1q/29NTG1drI7nL5jZTz3OgmcaQ27xasUX5HFVLR0U0WMers kqWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PIz5HY4g; spf=pass (google.com: domain of mptcp+bounces-5746-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="mptcp+bounces-5746-wpasupplicant.patchew=gmail.com@lists.linux.dev"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id k15-20020a635a4f000000b003fe1eedd7e9si19805767pgm.360.2022.06.21.10.23.49 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jun 2022 10:23:49 -0700 (PDT) Received-SPF: pass (google.com: domain of mptcp+bounces-5746-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PIz5HY4g; spf=pass (google.com: domain of mptcp+bounces-5746-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="mptcp+bounces-5746-wpasupplicant.patchew=gmail.com@lists.linux.dev"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 90B9E280ABA for ; Tue, 21 Jun 2022 17:23:49 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id AE2EF747B; Tue, 21 Jun 2022 17:23:48 +0000 (UTC) X-Original-To: mptcp@lists.linux.dev Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4B8EB4C94 for ; Tue, 21 Jun 2022 17:23:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655832226; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GPoTGIZrq9Vy19X8ghbSXhITg9eMi505n+T6Q/39T1I=; b=PIz5HY4go1DJZCOLa72ne2ETJU9ck2XP5dcVnTDWsuxa5R4ECyfw1QQNaoGp9zFP32fNeU IMhRUgLEFfOM66vaHTsz/HxtEk/6lSZYE0CaxvFnHzq5gNKXBKMko2MuGdu7iLmy25xJLN WEQxI7s6FjD4OinccM2LDbgEMvED260= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-195-saQgQk9MPfW9GXpjtKfGZA-1; Tue, 21 Jun 2022 13:23:40 -0400 X-MC-Unique: saQgQk9MPfW9GXpjtKfGZA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D8BE9811E75 for ; Tue, 21 Jun 2022 17:23:39 +0000 (UTC) Received: from gerbillo.redhat.com (unknown [10.39.193.164]) by smtp.corp.redhat.com (Postfix) with ESMTP id 44DB440CFD0A for ; Tue, 21 Jun 2022 17:23:39 +0000 (UTC) From: Paolo Abeni To: mptcp@lists.linux.dev Subject: [PATCH v5 mptcp-net 6/6] mptcp: fix race on unaccepted mptcp sockets Date: Tue, 21 Jun 2022 19:23:17 +0200 Message-Id: In-Reply-To: References: Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pabeni@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; x-default="true" When the listener socket owning the relevant request is closed, it frees the unaccepted subflows and that causes later deletion of the paired MPTCP sockets. The mptcp socket's worker can run in the time interval between such delete operations. When that happens, any access to msk->first will cause an UaF access, as the subflow cleanup did not cleared such field in the mptcp socket. Address the issue explictly traversing the listener socket accept queue at close time and performing the needed cleanup on the pending msk. Note that the locking is a bit tricky, as we need to acquire the msk socket lock, while still owning the subflow socket one. Fixes: 86e39e04482b ("mptcp: keep track of local endpoint still available f= or each msk") Signed-off-by: Paolo Abeni --- v3 -> v4: - use correct lockdep annotation when re-acquiring the listener sock lock --- net/mptcp/protocol.c | 5 +++++ net/mptcp/protocol.h | 2 ++ net/mptcp/subflow.c | 52 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 59 insertions(+) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 00ba9c44933a..6d2aa41390e7 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2318,6 +2318,11 @@ static void __mptcp_close_ssk(struct sock *sk, struc= t sock *ssk, kfree_rcu(subflow, rcu); } else { /* otherwise tcp will dispose of the ssk and subflow ctx */ + if (ssk->sk_state =3D=3D TCP_LISTEN) { + tcp_set_state(ssk, TCP_CLOSE); + mptcp_subflow_queue_clean(ssk); + inet_csk_listen_stop(ssk); + } __tcp_close(ssk, 0); =20 /* close acquired an extra ref */ diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h index ad9b02b1b3e6..95c9ace1437b 100644 --- a/net/mptcp/protocol.h +++ b/net/mptcp/protocol.h @@ -306,6 +306,7 @@ struct mptcp_sock { =20 u32 setsockopt_seq; char ca_name[TCP_CA_NAME_MAX]; + struct mptcp_sock *dl_next; }; =20 #define mptcp_data_lock(sk) spin_lock_bh(&(sk)->sk_lock.slock) @@ -610,6 +611,7 @@ void mptcp_close_ssk(struct sock *sk, struct sock *ssk, struct mptcp_subflow_context *subflow); void mptcp_subflow_send_ack(struct sock *ssk); void mptcp_subflow_reset(struct sock *ssk); +void mptcp_subflow_queue_clean(struct sock *ssk); void mptcp_sock_graft(struct sock *sk, struct socket *parent); struct socket *__mptcp_nmpc_socket(const struct mptcp_sock *msk); =20 diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 5c87a269af80..ec54ec72f113 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -1723,6 +1723,58 @@ static void subflow_state_change(struct sock *sk) } } =20 +void mptcp_subflow_queue_clean(struct sock *listener_ssk) +{ + struct request_sock_queue *queue =3D &inet_csk(listener_ssk)->icsk_accept= _queue; + struct mptcp_sock *msk, *next, *head =3D NULL; + struct request_sock *req; + + /* build a list of all unaccepted mptcp sockets */ + spin_lock_bh(&queue->rskq_lock); + for (req =3D queue->rskq_accept_head; req; req =3D req->dl_next) { + struct mptcp_subflow_context *subflow; + struct sock *ssk =3D req->sk; + struct mptcp_sock *msk; + + if (!sk_is_mptcp(ssk)) + continue; + + subflow =3D mptcp_subflow_ctx(ssk); + if (!subflow || !subflow->conn) + continue; + + /* skip if already in list */ + msk =3D mptcp_sk(subflow->conn); + if (msk->dl_next || msk =3D=3D head) + continue; + + msk->dl_next =3D head; + head =3D msk; + } + spin_unlock_bh(&queue->rskq_lock); + if (!head) + return; + + /* can't acquire the msk socket lock under the subflow one, + * or will cause ABBA deadlock + */ + release_sock(listener_ssk); + + for (msk =3D head; msk; msk =3D next) { + struct sock *sk =3D (struct sock *)msk; + bool slow; + + slow =3D lock_sock_fast_nested(sk); + next =3D msk->dl_next; + msk->first =3D NULL; + msk->dl_next =3D NULL; + unlock_sock_fast(sk, slow); + } + + /* we are still under the listener msk socket lock */ + lock_sock_nested(listener_ssk, SINGLE_DEPTH_NESTING); +} + static int subflow_ulp_init(struct sock *sk) { struct inet_connection_sock *icsk =3D inet_csk(sk); --=20 2.35.3