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 1AA5F4218AA; Fri, 4 Sep 2026 06:16:47 +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=1788502609; cv=none; b=pFpYlghTg7Bh62FKoiot4dpzkAleN9NsoHSAVcLk2B0qdaFTqM3pAU4QUkiXXwnEtbsIZ68oDFgKY9Jhzda8tjO0jTSOE0pYgW6oeomEmfI62BLAUxax64X+WSwg9/df8vPhsKX+Ne+s5ZRtBwfjbrZtx/VO3pZUbWoRazdUBSc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788502609; c=relaxed/simple; bh=ip1mmaXX2gMe7kBgponJbT8UV/2O/xPOC6dJs8DJYYE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FGAtBpe87DfpqiH6y0qaRLFPVCO56uCiggtkdBJrmZp3slCQ2s/padeglM35suIpvxG8CAOFAj5zJOt+aw42IeSNhZnKoO+QmREb3KdAYspqvKQj7WTnbFmDA0qV+djjrTUY6rkI2j/t5LH59FsQtmH1Oua5y3qTWMLOfeSQmvU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=uM+7qngK; 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="uM+7qngK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 287AB1F00A3D; Fri, 4 Sep 2026 06:16:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1788502607; bh=7jHzQouyVoFFxq0ZzR/7u7tyG1OxAJ6T8Ai5V78Lh6k=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=uM+7qngKTGqyZxGNdgVZs3YjxdchONmT6CvYIsgZ3moQ5dMABuyXEe2t6u8Gu8tGv MM9wmULR1THwD+Rr7eVXSiBnHvc9wA9YJjjDrzrFAJNspTD3iqOru1bj9LiDUp3HV7 pF96ojEEmaqLnX2r50NeHP/XkmH0yZxZsaYhsAoQ= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Hyunwoo Kim , Xin Long , Jakub Kicinski Subject: [PATCH 6.12 265/403] sctp: stop processing a packet once its association is deleted Date: Fri, 4 Sep 2026 07:01:08 +0200 Message-ID: <20260904045740.887319445@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260904045734.806166532@linuxfoundation.org> References: <20260904045734.806166532@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 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Hyunwoo Kim commit 47e15a8d12e366d0d261bcbc394394f44418938d upstream. sctp_endpoint_bh_rcv() looks the association up only when chunk->asoc is NULL, and caches the result in chunk->asoc and chunk->transport without taking a reference. A packet that matches no association is handed to the endpoint, so a peer can bundle COOKIE ECHO, SHUTDOWN and SHUTDOWN ACK in one packet. The COOKIE ECHO creates the association, the SHUTDOWN chunk caches it, and with the outqueue empty the SHUTDOWN ACK reaches sctp_sf_do_9_2_final(), so the association and its transports are freed. The endpoint loop has no counterpart to the asoc->base.dead check in sctp_assoc_bh_rcv(). The next chunk writes to last_time_heard in the freed transport and is then passed to sctp_do_sm() with the freed association. The transport is freed through RCU, so this needs the packet to come off the socket backlog, where the loop runs in task context. The endpoint loop cannot do the same check: it holds no reference on the association, so reading asoc->base.dead would itself be a use-after-free. Mark the packet for discard in the command interpreter, just before it deletes the association. That is also before sctp_inq_free() releases the chunk on the association receive path. sctp_sf_do_5_2_4_dupcook() issues SCTP_CMD_DELETE_TCB for the temporary association, while the one the packet belongs to stays alive. A restarting peer can bundle DATA behind its COOKIE ECHO, so compare against chunk->asoc and leave that case alone. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim Acked-by: Xin Long Link: https://patch.msgid.link/an-YYtoqw1QpTXUL@v4bel Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman --- net/sctp/sm_sideeffect.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/net/sctp/sm_sideeffect.c +++ b/net/sctp/sm_sideeffect.c @@ -1326,6 +1326,10 @@ static int sctp_cmd_interpreter(enum sct sctp_outq_uncork(&asoc->outqueue, gfp); local_cork = 0; } + /* No chunk left in this packet may use this asoc. */ + if (event_type == SCTP_EVENT_T_CHUNK && + chunk->asoc == asoc) + chunk->pdiscard = 1; /* Delete the current association. */ sctp_cmd_delete_tcb(commands, asoc); asoc = NULL;