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: <Y4gFt9GBRyv3kl2Y@lunn.ch>
Date:   Thu, 1 Dec 2022 02:39:03 +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
Subject: Re: [PATCH net] stmmac: fix potential division by 0

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?

I'm wondering if the correct thing to do is return -EINVAL in
stmmac_init_tstamp_counter().

So i would like an explanation of why it is zero.

Thanks
	Andrew