From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) (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 8E2F521CFE0 for ; Fri, 10 Jul 2026 01:07:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783645645; cv=none; b=IwLikYSRrnzrpaYJqvkhmrEAJ43orrBKxgWbGZKUotpa5kyJu+/rvBec4mWxgwD6EjFO8JB+snLUSOtE5fXxQmeSq50wTKjMVjwcL6F5264hQYVg8ySu6+1QcAOTAPL0hl9St9kBcVg+kEBpkQUODtZV8JKx6e1HQir7ODEbznw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783645645; c=relaxed/simple; bh=/80AeMdn4kk8+3llG/Z1EZupQkn+3RUdjZp2bGBYLQU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=sHKRYTI5k6qOQfVJ5c01H05Ym1hjSmKsp/GPB1WKTKdbvM/lvaGzLdSPY3qvoEV6SOBL3uOq67HQBdnp51dqu/rsaMxz8N80sEhH3ENKnCmB7wAuiFkPBDrjM3rVbro3+f8viLxCLyAOJptwxfyUfOIvmMikVr3m8UDIxxNBykU= 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=JVNB8gSy; arc=none smtp.client-ip=209.85.210.175 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="JVNB8gSy" Received: by mail-pf1-f175.google.com with SMTP id d2e1a72fcca58-84862b0d5aeso307815b3a.2 for ; Thu, 09 Jul 2026 18:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783645643; x=1784250443; 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=eLuU5HyvYLKGf+ae1L1IKeF030+aNKovcX3x67WIV9M=; b=JVNB8gSy6q4K1SlOdB0PF6OM3Bq3B1p5+x3WpZex0JfboMU8Dr5s2tiDKlyXl5ZSFO oTRw16bzhNKJDltm4iHqk3QXmFB+AhyKA0qDj8klKbz/+pKWlHA3bMwmk2S8mTSj+Y6l UZnyyJj+Ze3alkvB7XfPTEu56lM/RmCFs6IGiE1jFQOXcpGI3MPNOyZySeilf+WJmmoo jA8xR70zpjPMwy8ykQx4wyqiuWtpjQXRIGCcNl7kFqT7N8+B+cye3EVGZG/PzqV1D2xO o5pU4ndfxmR5QlYq6sk6EtqYCdiyl+EkP47AkgtxO1ISTkRKays8Q/DkBP6H75BQD07v z3+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783645643; x=1784250443; 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=eLuU5HyvYLKGf+ae1L1IKeF030+aNKovcX3x67WIV9M=; b=H7uPIKfIZvbsUoNyXhrPknKeEC+diRCn7jVe+WM7FE2jF+upskUM1Hfk7WkE3JeyJT /m9qCyaSbY6FQwTg34qapMycfjc6C/RZRcqwvfDKrPljkfxyErNTwWdjQo4WaDCF+EfF IjZ0ypPTrZlTxWcosN96ek7WrWMBOuHqwbaCQNyDGqjiJWZ2eDdx/wqx8e0c8v6e7Mji wv+ilqZpNlH+AfXyydJqyDW4YaFSHgQsbdslzEiFiilVQq7XgphlC7gwYbbOctxUVP66 EMHXBRqz7pmsR5RUlqZo6kDhpJDSjhnxMvbzhRYVTJBp0AK4i6qoNacv9qQlRe3oHIOk eTDA== X-Forwarded-Encrypted: i=1; AHgh+Rq4yjZf1WLpTNPXtDb+oeHrqyrBSz+abwv1SVamMidxHP+utYJZBniSGhKE+zlBrMqNTGpYJXQ0hsA+fSE=@vger.kernel.org X-Gm-Message-State: AOJu0YxyML3F6357DXGAYfSjTzMSeUeSZIIStmGo82XTSkhi46SQd0ey 8+JjhOKEXkYHsIw1r+7+7yWHS1yDEP3TeuTQ7TUa6LiEZScY1ZQTgfrF X-Gm-Gg: AfdE7cmf/Fe6yGcNlF9qtQ3uPGlYF9gOArriXn4ymKvcPt+UQMQ/NGT3e/YTVdINwbb bfnDA6Zy6BV+mNWK3mqxA4O0yCKDjx5JGrjqAoT8ZK06ngYyCX3y12wRpUDC6yUNBMrnJzpeebY mS6kR4DTffwOnnOPcTyb6q7U4FhiZrnEES47cugSkJBSauOFtYCN0KU+d+10sUKRnuCGksPRHAu GLJdDFyjp3xXj3jtKsWXgl7l70VRkmjDzllX6bOLEfYW3a4kbR5jIqLVFmIy+RWhj0jZa2yR703 XYNBlm9Cwhdv4a+DmmJqgw/lE4vrz76kEP2jM+v1hjTLQIB3i/ctyAQZpr2y7GikyBocAivi/hF A2IdQt3/4E0IJbpKsBJzlmOcODiNtpapFj33A13fIWJI8dAmu70MwaNt1Vf1J7B+Cyl64wFvv+0 titj1Oo92I3sWvOeEME8Oz4Zg1phc1fQ== X-Received: by 2002:a05:6a00:8c4:b0:848:2f6e:e537 with SMTP id d2e1a72fcca58-8484324633bmr8250058b3a.75.1783645642610; Thu, 09 Jul 2026 18:07:22 -0700 (PDT) Received: from LAPTOP-83ECOPAB.localdomain ([167.220.148.19]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8486768c89dsm1197847b3a.17.2026.07.09.18.07.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jul 2026 18:07:22 -0700 (PDT) From: "Cen Zhang (Microsoft)" To: marcelo.leitner@gmail.com, lucien.xin@gmail.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com Cc: horms@kernel.org, linux-sctp@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, AutonomousCodeSecurity@microsoft.com, tgopinath@linux.microsoft.com, kys@microsoft.com, blbllhy@gmail.com Subject: [PATCH net v2] sctp: validate stream count in sctp_process_strreset_inreq() Date: Thu, 9 Jul 2026 21:07:18 -0400 Message-ID: <20260710010718.20318-1-blbllhy@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer. Fixes: 7f9d68ac944e ("sctp: implement sender-side procedures for SSN Reset Request Parameter") Reported-by: AutonomousCodeSecurity@microsoft.com Closes: https://lore.kernel.org/all/20260707203215.2752-1-blbllhy@gmail.com/ Suggested-by: Xin Long Signed-off-by: Cen Zhang (Microsoft) --- v2: Add the OUT request length check to the send path, as suggested by Xin Long. net/sctp/stream.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/net/sctp/stream.c b/net/sctp/stream.c index 5c2fdedea088..34ffe6c945a4 100644 --- a/net/sctp/stream.c +++ b/net/sctp/stream.c @@ -308,7 +308,8 @@ int sctp_send_reset_streams(struct sctp_association *asoc, goto out; param_len += str_nums * sizeof(__u16) + - sizeof(struct sctp_strreset_inreq); + (out ? sizeof(struct sctp_strreset_inreq) + : sizeof(struct sctp_strreset_outreq)); } if (param_len > SCTP_MAX_CHUNK_LEN - @@ -639,6 +640,9 @@ struct sctp_chunk *sctp_process_strreset_inreq( nums = (ntohs(param.p->length) - sizeof(*inreq)) / sizeof(__u16); str_p = inreq->list_of_streams; + if (nums * sizeof(__u16) + sizeof(struct sctp_strreset_outreq) > + SCTP_MAX_CHUNK_LEN - sizeof(struct sctp_reconf_chunk)) + goto out; for (i = 0; i < nums; i++) { if (ntohs(str_p[i]) >= stream->outcnt) { result = SCTP_STRRESET_ERR_WRONG_SSN; -- 2.53.0