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 04EBF18E02A; Fri, 7 Aug 2026 15:23:15 +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=1786116196; cv=none; b=UVFHVuvoyCzgLY9CfDqQn+S/gj3rCTdkUEGBA2MUDueAmCRuf9LaXpgaHGCbC9uhGI5VZnP+eWykxSrPTAWQvAsam5mbMSvpxlWta/gnajWCOnTaWFUVnr8xGJBP+BhwxM2DUq/JTEDCz9LFFADZhVuza/pzcVz/Kz++aKaNLRo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786116196; c=relaxed/simple; bh=9I5gqyE2++Ir7X9+dRCqoK8/s58Rh7PWc/hqrCg/p4k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jbl+WSs0U9dl70iS1j8vDIkM7xga7vUcflhikYPaPu88+j+NWVSGm54VA2prcJeB2KDGeQie2lqV922fEeCFVB/mIXLaJBLXQuHEhFtJT72gOGLyKKkny/Sc6JGTbohTibgjToqjgxjGclWW1Ld9iRmk3uDJf/Z/2wMpGbioX+k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=GYV1jdP8; 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="GYV1jdP8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 600BC1F000E9; Fri, 7 Aug 2026 15:23:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1786116194; bh=GXXy81jugxyvZf0/yiIRaSWlwrAxMMR0/VzYVROcYoQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=GYV1jdP8lMZgCSdHB29459+ehuzvDbuMgfdzrwzFcbJQrJfLfLhQnfuBDQezo6KxO 1EobDGs2Lp1MoEApxHXSyeTnk1fSatb9UYQa/aBpJVgpwZhPe49fhahyfwDfBE5dd5 asxLVcfiIwW+oCIq2xd5TVTsMqSRe4wNxDBQnVO0= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Yuxiang Yang , Xin Long , Jakub Kicinski Subject: [PATCH 6.6 145/261] sctp: reject stale cookies with mismatched verification tags Date: Fri, 7 Aug 2026 16:38:22 +0200 Message-ID: <20260807143418.494270081@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260807143415.358597922@linuxfoundation.org> References: <20260807143415.358597922@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.6-stable review patch. If anyone has any objections, please let me know. ------------------ From: Yuxiang Yang commit 9d8da8e0a9bce4a340af60dd0446bc7eb8d07587 upstream. sctp_unpack_cookie() skips cookie expiration checks whenever an association already exists. This is broader than the exception in RFC 9260 Section 5.2.4. For an existing association, Section 5.2.4 permits an expired State Cookie only when both Verification Tags in the cookie match the current association. Otherwise, the packet SHOULD be discarded and a Stale Cookie ERROR MUST be sent. The broad check lets an expired Action A restart cookie reach sctp_sf_do_dupcook_a(). In a runtime test with the default 60 second cookie lifetime, replaying such a cookie after 65 seconds returned a COOKIE-ACK and restarted the association. Check cookie expiration unless both Verification Tags match. This preserves the Action D exception for a lost COOKIE ACK while rejecting expired cookies in all other cases. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Yuxiang Yang Acked-by: Xin Long Link: https://patch.msgid.link/20260723225623.2658868-1-yangyx22@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman --- net/sctp/sm_make_chunk.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) --- a/net/sctp/sm_make_chunk.c +++ b/net/sctp/sm_make_chunk.c @@ -1821,9 +1821,9 @@ no_hmac: goto fail; } - /* Check to see if the cookie is stale. If there is already - * an association, there is no need to check cookie's expiration - * for init collision case of lost COOKIE ACK. + /* Check to see if the cookie is stale. RFC 9260 Section 5.2.4 + * exempts an expired cookie only when both Verification Tags match + * the current association. * If skb has been timestamped, then use the stamp, otherwise * use current time. This introduces a small possibility that * a cookie may be considered expired, but this would only slow @@ -1834,7 +1834,10 @@ no_hmac: else kt = ktime_get_real(); - if (!asoc && ktime_before(bear_cookie->expiration, kt)) { + if ((!asoc || + asoc->c.my_vtag != bear_cookie->my_vtag || + asoc->c.peer_vtag != bear_cookie->peer_vtag) && + ktime_before(bear_cookie->expiration, kt)) { suseconds_t usecs = ktime_to_us(ktime_sub(kt, bear_cookie->expiration)); __be32 n = htonl(usecs);