netdev - Re: Lockup in phy_probe() for MDIO device (Broadcom's switch)

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: <118886b0-43c3-5211-1474-97adf006c1a3@gmail.com>
Date:   Thu, 30 Sep 2021 13:22:51 +0200
From:   Rafał Miłecki <zajec5@...il.com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Network Development <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        BCM Kernel Feedback <bcm-kernel-feedback-list@...adcom.com>,
        Vivek Unune <npcomplete13@...il.com>
Subject: Re: Lockup in phy_probe() for MDIO device (Broadcom's switch)

On 30.09.2021 12:30, Rafał Miłecki wrote:
> On 30.09.2021 12:17, Russell King (Oracle) wrote:
>> On Thu, Sep 30, 2021 at 11:58:21AM +0200, Rafał Miłecki wrote:
>>> This isn't necessarily a PHY / MDIO regression. It could be some core
>>> change that exposed a PHY / MDIO bug.
>>
>> I think what's going on is that the switch device is somehow being
>> probed by phylib. It looks to me like we don't check that the mdio
>> device being matched in phy_bus_match() is actually a PHY (by
>> checking whether mdiodev->flags & MDIO_DEVICE_FLAG_PHY is true
>> before proceeding with any matching.)
>>
>> We do, however, check the driver side. This looks to me like a problem
>> especially when the mdio bus can contain a mixture of PHY devices and
>> non-PHY devices. However, I would expect this to also be blowing up in
>> the mainline kernel as well - but it doesn't seem to.
>>
>> Maybe Andrew can provide a reason why this doesn't happen - maybe we've
>> just been lucky with out-of-bounds read accesses (to the non-existent
>> phy_device wrapped around the mdio_device?)
> 
> I'll see if I can use buildroot to test unmodified kernel.

I've used buildroot to use unmodified 5.10.57 kernel.


Let me start with explaining that there are 2 b53 drivers.

1. OpenWrt downstream swconfig-based b53 driver
Its b53_mdio.c registers as PHY driver by calling phy_driver_register()

2. Upstream DSA-based b53 driver
Its b53_mdio.c registers as MDIO driver by using mdio_module_driver()


With buildroot + kernel 5.10.57 + upstream DSA-based b53 driver I can't
see phy_probe() called for the /mdio-mux@...03000/mdio@.../switch@0 .
I'm not sure why as I have CONFIG_B53_MDIO_DRIVER=y . Maybe it's some
PHY device vs. MDIO device thing?

I'll proceed with Russell's request for checking MDIO_DEVICE_FLAG_PHY
now.