linux-kernel - Re: [PATCH net v2] sctp: fix a potential buffer overflow in sctp_sched_set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZFJX3KLkcu4nON7l@t14s.localdomain>
Date:   Wed, 3 May 2023 09:47:24 -0300
From:   Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To:     Gavrilov Ilia <Ilia.Gavrilov@...otecs.ru>
Cc:     Kuniyuki Iwashima <kuniyu@...zon.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
        "lucien.xin@...il.com" <lucien.xin@...il.com>,
        "lvc-project@...uxtesting.org" <lvc-project@...uxtesting.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "nhorman@...driver.com" <nhorman@...driver.com>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "simon.horman@...igine.com" <simon.horman@...igine.com>
Subject: Re: [PATCH net v2] sctp: fix a potential buffer overflow in
 sctp_sched_set_sched()

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