Message ID | 20230502130316.2680585-1-Ilia.Gavrilov@infotecs.ru |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp596602vqo; Tue, 2 May 2023 06:06:59 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7ZUzzcd9QFPyZxc0hCrx0dkv1udUVO07FWBKfIx3ws61zRUkX6MnNMeTQ/tA/yK9N1PxaT X-Received: by 2002:a17:903:298e:b0:1a5:32d7:90f4 with SMTP id lm14-20020a170903298e00b001a532d790f4mr17777325plb.50.1683032819462; Tue, 02 May 2023 06:06:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683032819; cv=none; d=google.com; s=arc-20160816; b=kBCgUvDW4Sx4aRdV50d157TdDdsPwZt37/s77yCU84+OctkRmtHQs+YSPBgJDyGTmq p2eXlvEBFwnQ05mfTyrERKRNL3bDy0CsMjFviyF0QdBMCpy3m+X3rPNa/d25LhhBbD8Y d9VmingoxzuuCfnekdQDGw06FvWqg1It5yGMGAJmT/onQNY5kJorphpD7BNJeDkTvcCj Uw6c0tBDNDkDeTN+v4M5MGhlFBJFyG6KWHkl4NbjYjtqgA8D7Q4DWvQ25bWDoa3kqd12 xfBHUyQWKfeeYslZdStxjJ3hqvrWQCOTEr4xf8d9a+7XV+7yX0vWFaMMuur2OwV3CWX7 ck3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :content-language:accept-language:in-reply-to:references:message-id :date:thread-index:thread-topic:subject:cc:to:from:dkim-signature :dkim-filter; bh=XeUJxsBSQd1pjrQXTV5YP3H+DxqnTGptCJyjoilPwJg=; b=MuQUACuABFB7kBMkHnbyrbCNblFxHFDc00hzFQgQrmCVA9203Va9j+mpD6xZ09xvoR ZN6vkVKlsCbdN7lQL2Eu2sgLV1Dr/7Eb0QyBznhKiaqb/fJrfcC/qGu9+loVBAxJEMit jLnrV3fvAPoH1DSi3nk5MF3ANC2s9UyXZ4s4TYwqGeKxbplNitOLYmHJwzEe/WFhF3w+ K91Nat+X/GLqavkTtRaUdVmrwbKtLML4SY8Yv2/AipcPGgLSn2/VftrrSw0ozRxbmXz7 iPPRh4FKi9I+k9EksMb6RXKRwLxWmCqyL3bYwsv48Vq33fnEtdPFNzywfd9RYI896DBT 0N3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infotecs.ru header.s=mx header.b=DGsaepVY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=infotecs.ru Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u13-20020a170902e80d00b0019ca7d69673si34318411plg.196.2023.05.02.06.06.24; Tue, 02 May 2023 06:06:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@infotecs.ru header.s=mx header.b=DGsaepVY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=infotecs.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234347AbjEBNF3 (ORCPT <rfc822;rbbytesnap@gmail.com> + 99 others); Tue, 2 May 2023 09:05:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41918 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234029AbjEBNFD (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 2 May 2023 09:05:03 -0400 Received: from mx0.infotecs.ru (mx0.infotecs.ru [91.244.183.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 641CB5252; Tue, 2 May 2023 06:04:07 -0700 (PDT) Received: from mx0.infotecs-nt (localhost [127.0.0.1]) by mx0.infotecs.ru (Postfix) with ESMTP id 00E2910B66F1; Tue, 2 May 2023 16:03:25 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 mx0.infotecs.ru 00E2910B66F1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infotecs.ru; s=mx; t=1683032605; bh=XeUJxsBSQd1pjrQXTV5YP3H+DxqnTGptCJyjoilPwJg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=DGsaepVYzleqpK/ZFnyAanNKuYVsN+7vqFFjhly7VO7T2ke37yOfWvRGXkZkKAkQw U5cZcETyQBiRXSLU5ucnK2YSPaOMlu/dH4gw1dUKpA4/vpWx5p2jNBcn5+Kn8wND+r Uu8pTZnnuoV+0B8Ww4SC1ehiqo6qh4WznO9w6sy4= Received: from msk-exch-02.infotecs-nt (msk-exch-02.infotecs-nt [10.0.7.192]) by mx0.infotecs-nt (Postfix) with ESMTP id F0DE130A2CA0; Tue, 2 May 2023 16:03:24 +0300 (MSK) From: Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru> To: Simon Horman <simon.horman@corigine.com> CC: Neil Horman <nhorman@tuxdriver.com>, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>, Xin Long <lucien.xin@gmail.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, "Jakub Kicinski" <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, "linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "lvc-project@linuxtesting.org" <lvc-project@linuxtesting.org> Subject: [PATCH net v2] sctp: fix a potential buffer overflow in sctp_sched_set_sched() Thread-Topic: [PATCH net v2] sctp: fix a potential buffer overflow in sctp_sched_set_sched() Thread-Index: AQHZfPZ6+AjI4Yq7k0+w8RGcNMvKHg== Date: Tue, 2 May 2023 13:03:24 +0000 Message-ID: <20230502130316.2680585-1-Ilia.Gavrilov@infotecs.ru> References: <ZFD6UgOFeUCbbIOC@corigine.com> In-Reply-To: <ZFD6UgOFeUCbbIOC@corigine.com> Accept-Language: ru-RU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.17.0.10] x-exclaimer-md-config: 208ac3cd-1ed4-4982-a353-bdefac89ac0a Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 177118 [May 02 2023] X-KLMS-AntiSpam-Version: 5.9.59.0 X-KLMS-AntiSpam-Envelope-From: Ilia.Gavrilov@infotecs.ru X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Auth: dkim=none X-KLMS-AntiSpam-Info: LuaCore: 510 510 bc345371020d3ce827abc4c710f5f0ecf15eaf2e, {Tracking_from_domain_doesnt_match_to}, 127.0.0.199:7.1.2;infotecs.ru:7.1.1;d41d8cd98f00b204e9800998ecf8427e.com:7.1.1 X-MS-Exchange-Organization-SCL: -1 X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: Clean, bases: 2023/05/02 11:01:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2023/05/02 09:07:00 #21205017 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1764771379885762667?= X-GMAIL-MSGID: =?utf-8?q?1764787821454024431?= |
Series |
[net,v2] sctp: fix a potential buffer overflow in sctp_sched_set_sched()
|
|
Commit Message
Gavrilov Ilia
May 2, 2023, 1:03 p.m. UTC
The 'sched' index value must be checked before accessing an element of the 'sctp_sched_ops' array. Otherwise, it can lead to buffer overflow. Note that it's harmless since the 'sched' parameter is checked before calling 'sctp_sched_set_sched'. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations") Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Ilia.Gavrilov <Ilia.Gavrilov@infotecs.ru> --- V2: - Change the order of local variables - Specify the target tree in the subject net/sctp/stream_sched.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
Comments
On Tue, May 2, 2023 at 9:03 AM Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru> wrote: > > The 'sched' index value must be checked before accessing an element > of the 'sctp_sched_ops' array. Otherwise, it can lead to buffer overflow. > > Note that it's harmless since the 'sched' parameter is checked before > calling 'sctp_sched_set_sched'. > > Found by InfoTeCS on behalf of Linux Verification Center > (linuxtesting.org) with SVACE. > > Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations") > Reviewed-by: Simon Horman <simon.horman@corigine.com> > Signed-off-by: Ilia.Gavrilov <Ilia.Gavrilov@infotecs.ru> > --- > V2: > - Change the order of local variables > - Specify the target tree in the subject > net/sctp/stream_sched.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/net/sctp/stream_sched.c b/net/sctp/stream_sched.c > index 330067002deb..4d076a9b8592 100644 > --- a/net/sctp/stream_sched.c > +++ b/net/sctp/stream_sched.c > @@ -146,18 +146,19 @@ static void sctp_sched_free_sched(struct sctp_stream *stream) > int sctp_sched_set_sched(struct sctp_association *asoc, > enum sctp_sched_type sched) > { > - struct sctp_sched_ops *n = sctp_sched_ops[sched]; > struct sctp_sched_ops *old = asoc->outqueue.sched; > struct sctp_datamsg *msg = NULL; > + struct sctp_sched_ops *n; > struct sctp_chunk *ch; > int i, ret = 0; > > - if (old == n) > - return ret; > - > if (sched > SCTP_SS_MAX) > return -EINVAL; > > + n = sctp_sched_ops[sched]; > + if (old == n) > + return ret; > + > if (old) > sctp_sched_free_sched(&asoc->stream); > > -- > 2.30.2 Reviewed-by: Xin Long <lucien.xin@gmail.com>
On Tue, May 02, 2023 at 01:03:24PM +0000, Gavrilov Ilia wrote: > The 'sched' index value must be checked before accessing an element > of the 'sctp_sched_ops' array. Otherwise, it can lead to buffer overflow. Buffer overflow? Or you mean, read beyond the buffer and possibly a bad pointer dereference? Because the buffer itself is not written to. > > Note that it's harmless since the 'sched' parameter is checked before > calling 'sctp_sched_set_sched'. > > Found by InfoTeCS on behalf of Linux Verification Center > (linuxtesting.org) with SVACE. > > Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations") > Reviewed-by: Simon Horman <simon.horman@corigine.com> > Signed-off-by: Ilia.Gavrilov <Ilia.Gavrilov@infotecs.ru> > --- > V2: > - Change the order of local variables > - Specify the target tree in the subject > net/sctp/stream_sched.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/net/sctp/stream_sched.c b/net/sctp/stream_sched.c > index 330067002deb..4d076a9b8592 100644 > --- a/net/sctp/stream_sched.c > +++ b/net/sctp/stream_sched.c > @@ -146,18 +146,19 @@ static void sctp_sched_free_sched(struct sctp_stream *stream) > int sctp_sched_set_sched(struct sctp_association *asoc, > enum sctp_sched_type sched) > { > - struct sctp_sched_ops *n = sctp_sched_ops[sched]; > struct sctp_sched_ops *old = asoc->outqueue.sched; > struct sctp_datamsg *msg = NULL; > + struct sctp_sched_ops *n; > struct sctp_chunk *ch; > int i, ret = 0; > > - if (old == n) > - return ret; > - > if (sched > SCTP_SS_MAX) > return -EINVAL; > > + n = sctp_sched_ops[sched]; > + if (old == n) > + return ret; > + > if (old) > sctp_sched_free_sched(&asoc->stream); > > -- > 2.30.2
From: Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru> Date: Tue, 2 May 2023 13:03:24 +0000 > The 'sched' index value must be checked before accessing an element > of the 'sctp_sched_ops' array. Otherwise, it can lead to buffer overflow. OOB access ? But it's not true because it does not happen in the first place. > > Note that it's harmless since the 'sched' parameter is checked before > calling 'sctp_sched_set_sched'. > > Found by InfoTeCS on behalf of Linux Verification Center > (linuxtesting.org) with SVACE. > > Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations") > Reviewed-by: Simon Horman <simon.horman@corigine.com> > Signed-off-by: Ilia.Gavrilov <Ilia.Gavrilov@infotecs.ru> > --- > V2: > - Change the order of local variables > - Specify the target tree in the subject > net/sctp/stream_sched.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/net/sctp/stream_sched.c b/net/sctp/stream_sched.c > index 330067002deb..4d076a9b8592 100644 > --- a/net/sctp/stream_sched.c > +++ b/net/sctp/stream_sched.c > @@ -146,18 +146,19 @@ static void sctp_sched_free_sched(struct sctp_stream *stream) > int sctp_sched_set_sched(struct sctp_association *asoc, > enum sctp_sched_type sched) > { > - struct sctp_sched_ops *n = sctp_sched_ops[sched]; > struct sctp_sched_ops *old = asoc->outqueue.sched; > struct sctp_datamsg *msg = NULL; > + struct sctp_sched_ops *n; > struct sctp_chunk *ch; > int i, ret = 0; > > - if (old == n) > - return ret; > - > if (sched > SCTP_SS_MAX) > return -EINVAL; I'd just remove this check instead because the same test is done in the caller side, sctp_setsockopt_scheduler(), and this errno is never returned. This unnecessary test confuses a reader like sched could be over SCTP_SS_MAX here. Since the OOB access does not happen, I think this patch should go to net-next without the Fixes tag after the merge window. Thanks, Kuniyuki > > + n = sctp_sched_ops[sched]; > + if (old == n) > + return ret; > + > if (old) > sctp_sched_free_sched(&asoc->stream); > > -- > 2.30.2
On Tue, May 02, 2023 at 10:05:16AM -0700, Kuniyuki Iwashima wrote: > From: Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru> > Date: Tue, 2 May 2023 13:03:24 +0000 > > The 'sched' index value must be checked before accessing an element > > of the 'sctp_sched_ops' array. Otherwise, it can lead to buffer overflow. > > OOB access ? My thought as well. > But it's not true because it does not happen in the first place. > > > > > Note that it's harmless since the 'sched' parameter is checked before > > calling 'sctp_sched_set_sched'. > > > > Found by InfoTeCS on behalf of Linux Verification Center > > (linuxtesting.org) with SVACE. > > > > Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations") > > Reviewed-by: Simon Horman <simon.horman@corigine.com> > > Signed-off-by: Ilia.Gavrilov <Ilia.Gavrilov@infotecs.ru> > > --- > > V2: > > - Change the order of local variables > > - Specify the target tree in the subject > > net/sctp/stream_sched.c | 9 +++++---- > > 1 file changed, 5 insertions(+), 4 deletions(-) > > > > diff --git a/net/sctp/stream_sched.c b/net/sctp/stream_sched.c > > index 330067002deb..4d076a9b8592 100644 > > --- a/net/sctp/stream_sched.c > > +++ b/net/sctp/stream_sched.c > > @@ -146,18 +146,19 @@ static void sctp_sched_free_sched(struct sctp_stream *stream) > > int sctp_sched_set_sched(struct sctp_association *asoc, > > enum sctp_sched_type sched) > > { > > - struct sctp_sched_ops *n = sctp_sched_ops[sched]; > > struct sctp_sched_ops *old = asoc->outqueue.sched; > > struct sctp_datamsg *msg = NULL; > > + struct sctp_sched_ops *n; > > struct sctp_chunk *ch; > > int i, ret = 0; > > > > - if (old == n) > > - return ret; > > - > > if (sched > SCTP_SS_MAX) > > return -EINVAL; > > I'd just remove this check instead because the same test is done > in the caller side, sctp_setsockopt_scheduler(), and this errno > is never returned. > > This unnecessary test confuses a reader like sched could be over > SCTP_SS_MAX here. It's actualy better to keep the test here and remove it from the callers: they don't need to know the specifics, and further new calls will be protected already. > > Since the OOB access does not happen, I think this patch should > go to net-next without the Fixes tag after the merge window. Yup. > > Thanks, > Kuniyuki > > > > > > + n = sctp_sched_ops[sched]; > > + if (old == n) > > + return ret; > > + > > if (old) > > sctp_sched_free_sched(&asoc->stream); > > > > -- > > 2.30.2
С уважением, Илья Гаврилов Ведущий программист Отдел разработки АО "ИнфоТеКС" в г. Санкт-Петербург 127287, г. Москва, Старый Петровско-Разумовский проезд, дом 1/23, стр. 1 T: +7 495 737-61-92 ( доб. 4921) Ф: +7 495 737-72-78 Ilia.Gavrilov@infotecs.ru www.infotecs.ru On 5/2/23 20:49, Marcelo Ricardo Leitner wrote: > On Tue, May 02, 2023 at 10:05:16AM -0700, Kuniyuki Iwashima wrote: >> From: Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru> >> Date: Tue, 2 May 2023 13:03:24 +0000 >>> The 'sched' index value must be checked before accessing an element >>> of the 'sctp_sched_ops' array. Otherwise, it can lead to buffer overflow. >> >> OOB access ? > > My thought as well. > I'm sorry. Yes, I meant out-of-bounds access. >> But it's not true because it does not happen in the first place. >> >>> >>> Note that it's harmless since the 'sched' parameter is checked before >>> calling 'sctp_sched_set_sched'. >>> >>> Found by InfoTeCS on behalf of Linux Verification Center >>> (linuxtesting.org) with SVACE. >>> >>> Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations") >>> Reviewed-by: Simon Horman <simon.horman@corigine.com> >>> Signed-off-by: Ilia.Gavrilov <Ilia.Gavrilov@infotecs.ru> >>> --- >>> V2: >>> - Change the order of local variables >>> - Specify the target tree in the subject >>> net/sctp/stream_sched.c | 9 +++++---- >>> 1 file changed, 5 insertions(+), 4 deletions(-) >>> >>> diff --git a/net/sctp/stream_sched.c b/net/sctp/stream_sched.c >>> index 330067002deb..4d076a9b8592 100644 >>> --- a/net/sctp/stream_sched.c >>> +++ b/net/sctp/stream_sched.c >>> @@ -146,18 +146,19 @@ static void sctp_sched_free_sched(struct sctp_stream *stream) >>> int sctp_sched_set_sched(struct sctp_association *asoc, >>> enum sctp_sched_type sched) >>> { >>> -struct sctp_sched_ops *n = sctp_sched_ops[sched]; >>> struct sctp_sched_ops *old = asoc->outqueue.sched; >>> struct sctp_datamsg *msg = NULL; >>> +struct sctp_sched_ops *n; >>> struct sctp_chunk *ch; >>> int i, ret = 0; >>> >>> -if (old == n) >>> -return ret; >>> - >>> if (sched > SCTP_SS_MAX) >>> return -EINVAL; >> >> I'd just remove this check instead because the same test is done >> in the caller side, sctp_setsockopt_scheduler(), and this errno >> is never returned. >> >> This unnecessary test confuses a reader like sched could be over >> SCTP_SS_MAX here. > > It's actualy better to keep the test here and remove it from the > callers: they don't need to know the specifics, and further new calls > will be protected already. > I agree that the check should be removed, but I think it's better to keep the test on the calling side, because params->assoc_value is set as the default "stream schedule" for the socket and it needs to be checked too. static int sctp_setsockopt_scheduler(..., struct sctp_assoc_value *params, ...) { ... if (params->assoc_id == SCTP_FUTURE_ASSOC || params->assoc_id == SCTP_ALL_ASSOC) sp->default_ss = params->assoc_value; ... } >> >> Since the OOB access does not happen, I think this patch should >> go to net-next without the Fixes tag after the merge window. > > Yup. > >> >> Thanks, >> Kuniyuki >> >> >>> >>> +n = sctp_sched_ops[sched]; >>> +if (old == n) >>> +return ret; >>> + >>> if (old) >>> sctp_sched_free_sched(&asoc->stream); >>> >>> -- >>> 2.30.2
On Wed, May 03, 2023 at 09:08:17AM +0000, Gavrilov Ilia wrote: > >> This unnecessary test confuses a reader like sched could be over > >> SCTP_SS_MAX here. > > > > It's actualy better to keep the test here and remove it from the > > callers: they don't need to know the specifics, and further new calls > > will be protected already. > > > > I agree that the check should be removed, but I think it's better to > keep the test on the calling side, because params->assoc_value is set as > the default "stream schedule" for the socket and it needs to be checked too. > > static int sctp_setsockopt_scheduler(..., struct sctp_assoc_value > *params, ...) > { > ... > if (params->assoc_id == SCTP_FUTURE_ASSOC || > params->assoc_id == SCTP_ALL_ASSOC) > sp->default_ss = params->assoc_value; > ... > } Good point. But then, don't remove the check. Instead, just fix that ordering and make it less confusing. Otherwise you will be really making it prone to the OOB if a new call gets added that doesn't validate the parameter. Thanks, Marcelo
diff --git a/net/sctp/stream_sched.c b/net/sctp/stream_sched.c index 330067002deb..4d076a9b8592 100644 --- a/net/sctp/stream_sched.c +++ b/net/sctp/stream_sched.c @@ -146,18 +146,19 @@ static void sctp_sched_free_sched(struct sctp_stream *stream) int sctp_sched_set_sched(struct sctp_association *asoc, enum sctp_sched_type sched) { - struct sctp_sched_ops *n = sctp_sched_ops[sched]; struct sctp_sched_ops *old = asoc->outqueue.sched; struct sctp_datamsg *msg = NULL; + struct sctp_sched_ops *n; struct sctp_chunk *ch; int i, ret = 0; - if (old == n) - return ret; - if (sched > SCTP_SS_MAX) return -EINVAL; + n = sctp_sched_ops[sched]; + if (old == n) + return ret; + if (old) sctp_sched_free_sched(&asoc->stream);