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: <Y4m2wg+OFc7pHc/7@gvm01>
Date:   Fri, 2 Dec 2022 09:26: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,
        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 03:49:37PM +0100, Andrew Lunn wrote:
> 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

For reference, this is the log of the error.

/root # ifconfig eth0 up
[   95.062067] socfpga-dwmac ff700000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   95.076440] socfpga-dwmac ff700000.ethernet eth0: PHY [stmmac-0:08] driver [NCN26000] (irq=49)
[   95.095964] dwmac1000: Master AXI performs any burst length
[   95.101588] socfpga-dwmac ff700000.ethernet eth0: No Safety Features support found
[   95.109428] Division by zero in kernel.
[   95.113447] CPU: 0 PID: 239 Comm: ifconfig Not tainted 6.1.0-rc7-centurion3-1.0.3.0-01574-gb624218205b7-dirty #77
[   95.123686] Hardware name: Altera SOCFPGA
[   95.127695]  unwind_backtrace from show_stack+0x10/0x14
[   95.132938]  show_stack from dump_stack_lvl+0x40/0x4c
[   95.137992]  dump_stack_lvl from Ldiv0+0x8/0x10
[   95.142527]  Ldiv0 from __aeabi_uidivmod+0x8/0x18
[   95.147232]  __aeabi_uidivmod from div_u64_rem+0x1c/0x40
[   95.152552]  div_u64_rem from stmmac_init_tstamp_counter+0xd0/0x164
[   95.158826]  stmmac_init_tstamp_counter from stmmac_hw_setup+0x430/0xf00
[   95.165533]  stmmac_hw_setup from __stmmac_open+0x214/0x2d4
[   95.171117]  __stmmac_open from stmmac_open+0x30/0x44
[   95.176182]  stmmac_open from __dev_open+0x11c/0x134
[   95.181172]  __dev_open from __dev_change_flags+0x168/0x17c
[   95.186750]  __dev_change_flags from dev_change_flags+0x14/0x50
[   95.192662]  dev_change_flags from devinet_ioctl+0x2b4/0x604
[   95.198321]  devinet_ioctl from inet_ioctl+0x1ec/0x214
[   95.203462]  inet_ioctl from sock_ioctl+0x14c/0x3c4
[   95.208354]  sock_ioctl from vfs_ioctl+0x20/0x38
[   95.212984]  vfs_ioctl from sys_ioctl+0x250/0x844
[   95.217691]  sys_ioctl from ret_fast_syscall+0x0/0x4c
[   95.222743] Exception stack(0xd0ee1fa8 to 0xd0ee1ff0)
[   95.227790] 1fa0:                   00574c4f be9aeca4 00000003 00008914 be9aeca4 be9aec50
[   95.235945] 1fc0: 00574c4f be9aeca4 0059f078 00000036 be9aee8c be9aef7a 00000015 00000000
[   95.244096] 1fe0: 005a01f0 be9aec38 004d7484 b6e67d74

   Piergiorgio