netdev - Re: [PATCH] net: phy: micrel: Do not use kszphy

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: <YnJvM4YaQBR0VZqF@lunn.ch>
Date:   Wed, 4 May 2022 14:18:59 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Fabio Estevam <festevam@...il.com>
Cc:     kuba@...nel.org, davem@...emloft.net, claudiu.beznea@...rochip.com,
        netdev@...r.kernel.org, o.rempel@...gutronix.de,
        linux@...linux.org.uk, Fabio Estevam <festevam@...x.de>,
        stable@...r.kernel.org
Subject: Re: [PATCH] net: phy: micrel: Do not use kszphy_suspend/resume for
 KSZ8061

On Wed, May 04, 2022 at 08:47:03AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@...x.de>
> 
> Since commit f1131b9c23fb ("net: phy: micrel: use
> kszphy_suspend()/kszphy_resume for irq aware devices") the following
> NULL pointer dereference is observed on a board with KSZ8061:
> 
>  # udhcpc -i eth0
> udhcpc: started, v1.35.0
> 8<--- cut here ---
> Unable to handle kernel NULL pointer dereference at virtual address 00000008
> pgd = f73cef4e
> [00000008] *pgd=00000000
> Internal error: Oops: 5 [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 196 Comm: ifconfig Not tainted 5.15.37-dirty #94
> Hardware name: Freescale i.MX6 SoloX (Device Tree)
> PC is at kszphy_config_reset+0x10/0x114
> LR is at kszphy_resume+0x24/0x64
> ...
> 
> The KSZ8061 phy_driver structure does not have the .probe/..driver_data
> fields, which means that priv is not allocated.
> 
> This causes the NULL pointer dereference inside kszphy_config_reset().
> 
> Fix the problem by using the generic suspend/resume functions as before.

Hi Fabio

Thanks for the fix. What you fail to mention is why not call
kszphy_probe() to populate priv? What makes this PHY special that it
does not need the probe call?

Looking at the ksphy_driver structure, this seems to affect
PHY_ID_KS8737 and PHY_ID_KSZ8061

     Thanks
	Andrew