netdev - Re: [PATCH net] net: dsa: sja1105: fix use-after-free after calling of_find_compatible

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:   Wed, 18 Aug 2021 01:31:01 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Alvin Šipraga <ALSI@...g-olufsen.dk>
Cc:     Vladimir Oltean <vladimir.oltean@....com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Frank Rowand <frowand.list@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Saravana Kannan <saravanak@...gle.com>
Subject: Re: [PATCH net] net: dsa: sja1105: fix use-after-free after calling
 of_find_compatible_node, or worse

Hi Alvin,

On Tue, Aug 17, 2021 at 09:25:28PM +0000, Alvin Šipraga wrote:
> I have an observation that's slightly out of the scope of your patch,
> but I'll post here on the off chance that you find it relevant.
> Apologies if it's out of place.
>
> Do these integrated NXP PHYs use a specific PHY driver, or do they just
> use the Generic PHY driver?

They refuse to probe at all with the Generic PHY driver. I have been
caught off guard a few times now when I had a kernel built with
CONFIG_NXP_C45_TJA11XX_PHY=n and their probing returns -22 in that case.

> If the former is the case, do you experience that the PHY driver fails
> to get probed during mdiobus registration if the kernel uses
> fw_devlink=on?

I don't test with "fw_devlink=on" in /proc/cmdline, this is the first
time I do it. It behaves exactly as you say.

>
> In my case I am writing a new subdriver for realtek-smi, a DSA driver
> which registers an internal MDIO bus analogously to sja1105, which is
> why I'm asking. I noticed a deferred probe of the PHY driver because the
> supplier (ethernet-switch) is not ready - presumably because all of this
> is happening in the probe of the switch driver. See below:
>
> [   83.653213] device_add:3270: device: 'SMI-0': device_add
> [   83.653905] device_pm_add:136: PM: Adding info for No Bus:SMI-0
> [   83.654055] device_add:3270: device: 'platform:ethernet-switch--mdio_bus:SMI-0': device_add
> [   83.654224] device_link_add:843: mdio_bus SMI-0: Linked as a sync state only consumer to ethernet-switch
> [   83.654291] libphy: SMI slave MII: probed
> ...
> [   83.659809] device_add:3270: device: 'SMI-0:00': device_add
> [   83.659883] bus_add_device:447: bus: 'mdio_bus': add device SMI-0:00
> [   83.659970] device_pm_add:136: PM: Adding info for mdio_bus:SMI-0:00
> [   83.660122] device_add:3270: device: 'platform:ethernet-switch--mdio_bus:SMI-0:00': device_add
> [   83.660274] devices_kset_move_last:2701: devices_kset: Moving SMI-0:00 to end of list
> [   83.660282] device_pm_move_last:203: PM: Moving mdio_bus:SMI-0:00 to end of list
> [   83.660293] device_link_add:859: mdio_bus SMI-0:00: Linked as a consumer to ethernet-switch
> [   83.660350] __driver_probe_device:736: bus: 'mdio_bus': __driver_probe_device: matched device SMI-0:00 with driver RTL8365MB-VC Gigabit Ethernet
> [   83.660365] device_links_check_suppliers:1001: mdio_bus SMI-0:00: probe deferral - supplier ethernet-switch not ready
> [   83.660376] driver_deferred_probe_add:138: mdio_bus SMI-0:00: Added to deferred list

So it's a circular dependency? Switch cannot finish probing because it
cannot connect to PHY, which cannot probe because switch has not
finished probing, which....

So how is it supposed to be solved then? Intuitively the 'mdio_bus SMI-0:00'
device should not be added to the deferred list, it should have everything
it needs right now (after all, it works without fw_devlink). No?

It might be the late hour over here too, but right now I just don't
know. Let me add Saravana to the discussion too, he made an impressive
analysis recently on a PHY probing issue with mdio-mux, so the PHY
library probing dependencies should still be fresh in his mind, maybe he
has an idea what's wrong.

>
> It's not necessarily fatal because phy_attach_direct will just use the
> Generic PHY driver as a fallback, but it's obviously not the intended
> behaviour.
>
> Perhaps this affects your driver too? Due to lack of hardware I am not
> in a position to test, but a static code analysis suggests it may be if
> you are expecting anything but Generic PHY.

Yeah, rest assured, you're not the only one.