From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D89ED405C3F for ; Thu, 30 Jul 2026 11:02:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785409374; cv=none; b=mGzVp1RKySNo0Q5WVn3YoFWVW0U2gVClCt+DWJIdpTQ3czCAyMzozIyfCKO1cs46C2HJTdlh5jh/eoWwKRhhsJxmPM67lGMm+P9hUmRaDj1Lrq2rkBqy2wEnI2PKfFbm3HybMKQ9ZcoXSE7TrqJD/1roTFcncdftct1zevSGEVY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785409374; c=relaxed/simple; bh=GLYj4y9qOcb+4URpLy99dPxoLwMSgIMPJmTKMxy/yBg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=T6F13N8Vh0F4onLue3JzHxawFFy/v1be1kh+Sk5vbIjP4xZv2XQhjPdcJIVb3MLxzJX9nnJB0LoRPItKbsPyYLIpD37I3yRiIwwMRctE72BsCTF07wyscrqw7hHwZr/z09Y3tPTZlQCuDuxcex7V+a0kNZovhSA8jBK8SMrUKgI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=QrndH/qH; arc=none smtp.client-ip=209.85.214.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QrndH/qH" Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-2ce87c7e3bbso22454375ad.1 for ; Thu, 30 Jul 2026 04:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785409372; x=1786014172; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=VfJWXRx7XSYo0yICaQTUNXgfXIN1L4L4orSeuNAFQFw=; b=QrndH/qHpZ+8ow8JHFOzfd7VxPOoxsnV5fWjh1y4C+0yKoYXcu8ucWsqPXKsXEo8jx EJeff6KZBkWT6EpKYOmOYjo1T7OFvPr+NBOQUD8rcGgYRQjwiFpJtw4z/Tlh1PRgdO9d V1973WuA7sfnZWUkvoCbHrWI5NDScGTt1kszomAmR8wMak2ZPBq/fo3GGOFaTxY/6Gzl qHQWmLo4/T17xN1EpjJKswmImbFMdh8jiTcEFD9pgqigHwwdXpFXucYaKfMD4l3SVgHK arfx5o4QnXqb1xZ0c1PzbGrf3T7iMqw1GtEmOTmIjrUHR2dJrjuriHBAbQsV/NdFfQeC /oTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785409372; x=1786014172; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=VfJWXRx7XSYo0yICaQTUNXgfXIN1L4L4orSeuNAFQFw=; b=rER45VKOrVDMriGxRKkt5tcjw3bYeyvLOH/xEAHFX5Ab+eRaIItbxAuLofMVqxvef4 mS042NG5piV9VszBE+PviZrupfqCHA+QyR3iTuiLrGiVUYm40c7D0Fk1EvgFxhV2T6xI T+hAIpCfsxEdeWfQGLF8urOXYT4rEOBUeJeuE4vQ+m98ZRgrMX9hDQ55MoBUYDMow5Kl 4ENcsAq3jvdNu76TrV5lHeg3BapvrExohYEJJymIyJst40XZlMRjOEU+R/9T9DssgP4r OMUMWrGVl6NA+kmCH62n/6v3ijTQrZXidbznDN47zd/4mlwedNGkS2zfrbYPhTKNHY5t efdQ== X-Forwarded-Encrypted: i=1; AHgh+RrAxz25Ie8lrb/LmH8LIoj2qePbN5SiBT8lRVhxKJAt8nmjXVSIIVGJt24GlJ99AbmX3x/hOeULtoWi2p0=@vger.kernel.org X-Gm-Message-State: AOJu0Yz1S8hemdR5z3aDeb6KXh9uXvFwldl7C3bNZtUID16ueJb28kYN OP7Y4v2Gzr4yibUkpr9aWco64DszcLcnI7TLGEoPWJn2AKP7dMInUU81 X-Gm-Gg: AR+sD11NmhjuYxv3PMAR9Jqvu96biZID3Aw7A/jUANJJWcRmwqpAHM3qg58TmXfHkSp Jf4EKcXG6Z6gcEwg504IEo4hvX+H/hz6Uj+xX4MY0Fv/jX+J0fgfY2e7HQCGSvY86YzHW33AExS J1NV+uEFXvHFhLcARiJBak7NEy4M3tFZ1/OnZ50RkT8ZAT5sXFguSIH8n++SJkcZfALFEMNhlKK PORYfzCy495BfS59LpGoy0DhTMwgklyIJbTb+trhTmL0kLLItbdChIbsktWKZB7JueIK36HqzL/ +i8meY2284swv7VuOrSNDJDgv9mAF+h44/J6+kEi2ccvySV/zFACaw1OsZ6gMPVOzjP3Ai7nK/3 YSTXaVCIcFR1/XOVBaeGyxVD7czWLGbfPWuonns09SmAIRsZwfzQ++Gp8MRzDPMwPZuFnew0QC1 3/rbeBQU7yOTLZl1CcLGDj0ZEq0tzYofpcrohGxncco6TTxxuMgZUahW/GxEcZWVE8hc1FEEXo0 /lpe1a7NYZGQ9/ME9+FYU/BujMMPue7Mj15+bc= X-Received: by 2002:a17:90b:4b8b:b0:381:f7a:2e0d with SMTP id 98e67ed59e1d1-38f9bee90e8mr1637384a91.33.1785409371973; Thu, 30 Jul 2026 04:02:51 -0700 (PDT) Received: from JUNVYYANG-MC1.tencent.com ([43.132.141.21]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-38f9b42d1a3sm873014a91.2.2026.07.30.04.02.48 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Thu, 30 Jul 2026 04:02:51 -0700 (PDT) From: Jun Yang To: netdev@vger.kernel.org Cc: Jun Yang , stable@kernel.org, TencentOS Corvus AI , Marcelo Ricardo Leitner , Xin Long , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , linux-sctp@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH net] sctp: fix stream->outcnt underflow on duplicate RECONF responses Date: Thu, 30 Jul 2026 19:02:19 +0800 Message-ID: <20260730110225.37371-1-juny24602@gmail.com> X-Mailer: git-send-email 2.50.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Jun Yang sctp_process_strreset_resp() rolls back a denied ADD_OUT_STREAMS request by subtracting the requested count from the current stream count: nums = ntohs(addstrm->number_of_streams); number = stream->outcnt - nums; /* net/sctp/stream.c:1050 */ ... stream->outcnt = number; /* net/sctp/stream.c:1060 */ This undoes the increment sctp_send_add_streams() performed at request time, and is only correct if it runs exactly once per request. Nothing enforces that. The function does not check asoc->strreset_outstanding on entry; it only decrements it at the tail, and asoc->strreset_chunk - the only thing sctp_chunk_lookup_strreset_param() consults - stays live until that counter reaches zero. When both outgoing and incoming streams are added in one setsockopt(SCTP_ADD_STREAMS), sctp_send_add_streams() sets strreset_outstanding to 2 and caches a chunk holding both the ADD_OUT and ADD_IN parameters. sctp_verify_reconf() permits a RESET_RESPONSE to follow another RESET_RESPONSE, and the lookup accepts any request still present in the cached chunk. A peer can therefore put two responses carrying the ADD_OUT request_seq into a single RECONF chunk. sctp_sf_do_reconf() processes both: the first rollback restores the original count and the second subtracts nums again. Depending on the counts, this either wraps the __u16 or silently shrinks the stream count a second time. SCTP_SO() is genradix_ptr(), which returns NULL past the preallocated range, so sctp_sendmsg_to_asoc() accepts an out-of-range stream id at net/sctp/socket.c:1803 and dereferences the resulting NULL slot at net/sctp/socket.c:1808. Other stream walkers likewise trust the inflated count until a later operation repairs or tears down the association. Only accept the response sequence currently named by strreset_outseq. Each accepted response advances that sequence, so a duplicate becomes stale even while another request parameter remains outstanding. Also reject a response whose count exceeds the current stream count as a defence-in-depth check on the subtraction. Fixes: 11ae76e67a17 ("sctp: implement receiver-side procedures for the Reconf Response Parameter") Cc: stable@kernel.org Reported-by: TencentOS Corvus AI Signed-off-by: Jun Yang --- net/sctp/stream.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/net/sctp/stream.c b/net/sctp/stream.c index 34ffe6c945a4..b751d0843b3d 100644 --- a/net/sctp/stream.c +++ b/net/sctp/stream.c @@ -927,6 +927,14 @@ struct sctp_chunk *sctp_process_strreset_resp( struct sctp_paramhdr *req; __u32 result; + /* Process responses in request sequence. strreset_outseq advances after + * each accepted response, so this also rejects duplicate responses while + * another parameter from the same RECONF chunk remains outstanding. + */ + if (!asoc->strreset_outstanding || + resp->response_seq != htonl(asoc->strreset_outseq)) + return NULL; + req = sctp_chunk_lookup_strreset_param(asoc, resp->response_seq, 0); if (!req) return NULL; @@ -1047,6 +1055,8 @@ struct sctp_chunk *sctp_process_strreset_resp( addstrm = (struct sctp_strreset_addstrm *)req; nums = ntohs(addstrm->number_of_streams); + if (nums > stream->outcnt) + return NULL; number = stream->outcnt - nums; if (result == SCTP_STRRESET_PERFORMED) { -- 2.55.0