linux-kernel - RE: [PATCH v3 2/2] clk:mmp: clk-mix.c fix divide-by-zero

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] [day] [month] [year] [list]

Message-ID: <155613934508.15276.10077721853967398026@swboyd.mtv.corp.google.com>
Date:   Wed, 24 Apr 2019 13:55:45 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     "chao.xie@...vell.com" <chao.xie@...vell.com>,
        "jbrunet@...libre.com" <jbrunet@...libre.com>,
        "mojha@...eaurora.org" <mojha@...eaurora.org>,
        "mturquette@...libre.com" <mturquette@...libre.com>,
        "sboyd@...eaurora.org" <sboyd@...eaurora.org>,
        "soren.brinkmann@...inx.com" <soren.brinkmann@...inx.com>,
        Nixiaoming <nixiaoming@...wei.com>
Cc:     "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3 2/2] clk:mmp: clk-mix.c fix divide-by-zero

Quoting Nixiaoming (2019-04-24 08:34:54)
> On Wed, Apr 24, 2019 at 7:00 AM Stephen Boyd <sboyd@...nel.org> wrote:
> >Quoting nixiaoming (2019-03-30 06:55:42)
> >> The _get_div() function has a branch with a return value of 0
> >> Add a check on the return value of _get_div() to avoid divide-by-zero
> >> 
> >
> >Are you seeing this in practice? Or just trying to avoid a div-by-zero
> >case that you've found from inspection? 
> >
> This potential bug is found by code inspection.
> _get_div() is defined as a static function which is only refered twice 
> in drivers/clk/mmp/clk-mix.c. In both cases the return value of _get_div()
>  is used as divider without any check.
>  If _get_div() never returns 0, then the branch returning 0 is dead code,
> or the return value should be check to avoid dividing by zero error. 
> 

Ok. If it's found by code inspection then I'd rather wait until someone
can confirm what the behavior should be when _get_div() returns 0. Is it
an error case that never happens or does the hardware support 0 as a
divider value meaning "bypass"? I'd like to understand that before
patching up a potential div-by-zero case and not knowing what it means.