netdev - Re: [PATCH net] stmmac: fix potential division by 0

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:   Thu, 1 Dec 2022 15:49:37 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Piergiorgio Beruto <piergiorgio.beruto@...il.com>
Cc:     kuba@...nel.org, netdev@...r.kernel.org, peppe.cavallaro@...com,
        Voon Weifeng <weifeng.voon@...el.com>,
        Rayagond Kokatanur <rayagond@...avyalabs.com>,
        Jose Abreu <Jose.Abreu@...opsys.com>,
        Antonio Borneo <antonio.borneo@...com>,
        Tan Tee Min <tee.min.tan@...el.com>,
        Kurt Kanzenbach <kurt@...utronix.de>
Subject: Re: [PATCH net] stmmac: fix potential division by 0

On Thu, Dec 01, 2022 at 11:24:42AM +0100, Piergiorgio Beruto wrote:
> On Thu, Dec 01, 2022 at 02:39:03AM +0100, Andrew Lunn wrote:
> > On Thu, Dec 01, 2022 at 01:37:08AM +0100, Piergiorgio Beruto wrote:
> > > Depending on the HW platform and configuration, the
> > > stmmac_config_sub_second_increment() function may return 0 in the
> > > sec_inc variable. Therefore, the subsequent div_u64 operation can Oops
> > > the kernel because of the divisor being 0.
> > 
> > I'm wondering why it would return 0? Is the configuration actually
> > invalid? Is ptp_clock is too small, such that the value of data is
> > bigger than 255, but when masked with 0xff it gives zero?
> Ok, I did some more analysis on this. On my reference board, I got two
> PHYs connected to two stmmac, one is 1000BASE-T, the other one is
> 10BASE-T1S.
> 
> Fot the 1000BASE-T PHY everything works ok. The ptp_clock is 0ee6b280
> which gives data = 8 that is less than FF.
> 
> For the 10BASE-T1 PHY the ptp_clock is 001dcd65 which gives data = 400
> (too large). Therefore, it is 0 after masking.

So both too large, and also unlucky. If it had been 0x3ff you would
not of noticed.

> The root cause is the MAC using the internal clock as a PTP reference
> (default), which should be allowed since the connection to an external
> PTP clock is optional from an HW perspective. The internal clock seems
> to be derived from the MII clock speed, which is 2.5 MHz at 10 Mb/s.

I think we need help from somebody who understands PTP on this device.
The clock is clearly out of range, but how important is that to PTP?
Will PTP work if the value is clamped to 0xff? Or should we be
returning -EINVAL and disabling PTP because it has no chance of
working?

Add to Cc: a few people who have worked on the PTP code. Lets see what
they have to say.

     Andrew