linux-kernel - Re: [PATCH] net: sched: taprio: Fix potential integer overflow in taprio_set_picos_per

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: <CA+h21hpCAJhE8xhsgDQ55_MUUiesV=uVY4tD=TzaCE6wynUPoQ@mail.gmail.com>
Date:   Tue, 3 Sep 2019 13:12:41 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     "Gustavo A. R. Silva" <gustavo@...eddedor.com>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jiri Pirko <jiri@...nulli.us>,
        "David S. Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] net: sched: taprio: Fix potential integer overflow in taprio_set_picos_per_byte

On Tue, 3 Sep 2019 at 10:19, Eric Dumazet <eric.dumazet@...il.com> wrote:
>
>
>
> On 9/3/19 3:08 AM, Gustavo A. R. Silva wrote:
> > Add suffix LL to constant 1000 in order to avoid a potential integer
> > overflow and give the compiler complete information about the proper
> > arithmetic to use. Notice that this constant is being used in a context
> > that expects an expression of type s64, but it's currently evaluated
> > using 32-bit arithmetic.
> >
> > Addresses-Coverity-ID: 1453459 ("Unintentional integer overflow")
> > Fixes: f04b514c0ce2 ("taprio: Set default link speed to 10 Mbps in taprio_set_picos_per_byte")
> > Signed-off-by: Gustavo A. R. Silva <gustavo@...eddedor.com>
> > ---
> >  net/sched/sch_taprio.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
> > index 8d8bc2ec5cd6..956f837436ea 100644
> > --- a/net/sched/sch_taprio.c
> > +++ b/net/sched/sch_taprio.c
> > @@ -966,7 +966,7 @@ static void taprio_set_picos_per_byte(struct net_device *dev,
> >
> >  skip:
> >       picos_per_byte = div64_s64(NSEC_PER_SEC * 1000LL * 8,
> > -                                speed * 1000 * 1000);
> > +                                speed * 1000LL * 1000);
> >
> >       atomic64_set(&q->picos_per_byte, picos_per_byte);
> >       netdev_dbg(dev, "taprio: set %s's picos_per_byte to: %lld, linkspeed: %d\n",
> >
>
> But, why even multiplying by 1,000,000 in the first place, this seems silly,
> a standard 32 bit divide could be used instead.
>
> ->
>
> diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
> index 8d8bc2ec5cd6281d811fd5d8a5c5211ebb0edd73..944b1af3215668e927d486b6c6c65c4599fb9539 100644
> --- a/net/sched/sch_taprio.c
> +++ b/net/sched/sch_taprio.c
> @@ -965,8 +965,7 @@ static void taprio_set_picos_per_byte(struct net_device *dev,
>                 speed = ecmd.base.speed;
>
>  skip:
> -       picos_per_byte = div64_s64(NSEC_PER_SEC * 1000LL * 8,
> -                                  speed * 1000 * 1000);
> +       picos_per_byte = (USEC_PER_SEC * 8) / speed;
>
>         atomic64_set(&q->picos_per_byte, picos_per_byte);
>         netdev_dbg(dev, "taprio: set %s's picos_per_byte to: %lld, linkspeed: %d\n",
>
>
>

Right. And while we're at it, there's still the potential
division-by-zero problem which I still don't know how to solve without
implementing a full-blown __ethtool_get_link_ksettings parser that
checks against all the possible outputs it can have under the "no
carrier" condition - see "[RFC PATCH 1/1] phylink: Set speed to
SPEED_UNKNOWN when there is no PHY connected" for details.
And there's also a third fix to be made: the netdev_dbg should be made
to print "speed" instead of "ecmd.base.speed".

Thanks,
-Vladimir