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]

Message-ID: <Y4iA6mwSaZw+PKHZ@gvm01>
Date:   Thu, 1 Dec 2022 11:24:42 +0100
From:   Piergiorgio Beruto <piergiorgio.beruto@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     kuba@...nel.org, netdev@...r.kernel.org, peppe.cavallaro@...com
Subject: Re: [PATCH net] stmmac: fix potential division by 0

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.

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'm wondering if the correct thing to do is return -EINVAL in
> stmmac_init_tstamp_counter().
I've tried that as an alternate fix. The end result is:

/root # ifconfig eth0 up
[   17.535304] socfpga-dwmac ff700000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   17.549104] socfpga-dwmac ff700000.ethernet eth0: PHY [stmmac-0:08] driver [NCN26000] (irq=49)
[   17.568801] dwmac1000: Master AXI performs any burst length
[   17.574410] socfpga-dwmac ff700000.ethernet eth0: No Safety Features support found

[   17.595874] socfpga-dwmac ff700000.ethernet eth0: PTP init failed

[   17.605308] socfpga-dwmac ff700000.ethernet eth0: configuring for phy/mii link mode
[   17.613905] socfpga-dwmac ff700000.ethernet eth0: No phy led trigger registered for speed(10)
[   17.624558] socfpga-dwmac ff700000.ethernet eth0: Link is Up - 10Mbps/Half - flow control off

So as you can see the PTP initialization failed, but it soes not seem to
provoke any other unwanted effect.

The real question, in my opinion, is: are we ok just making it fail?
This is certainly good enough for my application, but others may have a
different opinion.

I would suggest to return an error for the time being (as it fixes the
Oops) then see whether a different fix is really needed.

Please, let me know your thoughts.

Kidn Regards,
Piergiorgio