netdev - Re: [net-next 05/14] i40e: fix up 32 bit timespec references

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]

Date:   Mon, 25 Feb 2019 08:47:59 -0800
From:   Jesse Brandeburg <jesse.brandeburg@...el.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        David Miller <davem@...emloft.net>,
        Networking <netdev@...r.kernel.org>, <nhorman@...hat.com>,
        <sassmann@...hat.com>, <jogreene@...hat.com>,
        jacob.e.keller@...el.com
Subject: Re: [net-next 05/14] i40e: fix up 32 bit timespec references

On Mon, 25 Feb 2019 15:46:18 +0100
Arnd Bergmann <arnd@...db.de> wrote:
> I just stumbled over code added by this older patch, and can't make sense
> of the commit description here. Was this an attempt to fix a bug, or
> just a cleanup?

Thanks Arnd for mentioning/posting this! This was an attempt at a clean
up, unfortunately I made a mistake which introduced a bug.

> > -       then = ns_to_timespec64(delta);
> >         mutex_lock(&pf->tmreg_lock);
> >
> >         i40e_ptp_read(pf, &now);
> > -       now = timespec64_add(now, then);
> > +       timespec64_add_ns(&now, delta);
> >         i40e_ptp_write(pf, (const struct timespec64 *)&now);
> 
> The problem I noticed here is that 'delta' is a user provided 64-bit
> number from clock_adjtime(), and timespec64_add_ns() performs uses
> a repeated addition instead of a div/mod pair. When the number
> is large, we may end up adding a single second 8 billion times,
> which may take a while even on a fast CPU.
> 
> Should the commit 0ac30ce43323 ("i40e: fix up 32 bit timespec
> references") just be reverted?

Interestingly, we just were discussing this fix this past Friday, and
have a patch internally to fix the issue correctly. Either way it
is a commit (revert or fix) so we might as well just send the fix ASAP.

Our team should have something posted to intel-wired-lan/netdev shortly,
and we'll get the patch officially to netdev  after a brief test.