From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 25F8341A4FF; Thu, 30 Jul 2026 14:49:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785422976; cv=none; b=jMYKhpOxd3HFHBwNtJCDtFT7ef6FqIK7PxHFrU12l+oxaHoUsELEWr/7iVDUBufs2VBB2wsq0QFAViXV1rjJjBCRf87Aj6hI5qSNFfMkW0rcs5NOCtas8Wx2FJ+soksuLRO+3r1+VYl1y1nhWx4Ziroqr/BdS4pAxSJBTkZr9NI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785422976; c=relaxed/simple; bh=BbVD5drRQm8DomibgD2k+iR+WLUY9AFOnxcelDjJuhs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oEuD430pK+CRb2LbI9RFVOhHy+qne9Qr0+c8Z4DvhqzK/dHGU64spX+68kFvdozxfWHgWH9ZApq+UfBnfAnqOexy/Oa7BSiP6bJXU8+c/J2Rd2mpz1C6fwZNB018bzGcb8vobdw4ZF3/OjpUwS/27gUI1Dbl0AqffaRFn2yNODI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=uQiZyPtH; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="uQiZyPtH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D06D1F000E9; Thu, 30 Jul 2026 14:49:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1785422975; bh=oCpOzQT4tsdprUV/47l85UuGThF7irrXhqAvB+ZD2/U=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=uQiZyPtHhBvh8R8RwUtZWrQ8WRKqy63B9f4EeAj8xEBycQIjIeJO5ANMX98SW8BpQ 7GWJozWXbf6QDYQCUvtYDvTMFp+x4DSjUSBI8bZjjyalOJkCIcuXGKMukp2pM/FitR N29pcGkPbqQwkUrLm/tcW3x3y2sGc0yU/6Y7XFzs= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, stable@kernel.org, Jun Yang , Xin Long , Jakub Kicinski Subject: [PATCH 7.1 622/744] sctp: dont free the ASCONFs own transport in DEL-IP processing Date: Thu, 30 Jul 2026 16:14:55 +0200 Message-ID: <20260730141457.496474804@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260730141444.267951807@linuxfoundation.org> References: <20260730141444.267951807@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 7.1-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jun Yang commit 9b2854f86f0b56e9027d68e7a3fc909d1a9b566f upstream. sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport. Fixes: 42e30bf3463c ("[SCTP]: Handle the wildcard ADD-IP Address parameter") Cc: stable@kernel.org Signed-off-by: Jun Yang Acked-by: Xin Long Link: https://patch.msgid.link/tencent_73762ED1DF08CC9D5F5F61954B01350CFE0A@qq.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman --- net/sctp/sm_make_chunk.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/net/sctp/sm_make_chunk.c +++ b/net/sctp/sm_make_chunk.c @@ -3153,6 +3153,12 @@ static __be16 sctp_process_asconf_param( if (!peer) return SCTP_ERROR_DNS_FAILED; + /* Don't free asconf->transport; a later wildcard DEL-IP + * parameter reuses it. + */ + if (peer == asconf->transport) + return SCTP_ERROR_REQ_REFUSED; + sctp_assoc_rm_peer(asoc, peer); break; case SCTP_PARAM_SET_PRIMARY: