Re:Re: [PATCH net] net: phy: micrel: Fix potential shared PHC use-after-free
From: 李广硕
Date: Mon Nov 09 2026 - 08:09:58 EST
Hi Andrew,
From: Andrew Lunn <andrew@xxxxxxx>
Date: 2026-11-07 22:40:45
To: Guangshuo Li <liguangshuo@xxxxxxxxxxxxxxx>
Cc: Heiner Kallweit <hkallweit1@xxxxxxxxx>,Russell King <linux@xxxxxxxxxxxxxxx>,"David S. Miller" <davem@xxxxxxxxxxxxx>,Eric Dumazet <edumazet@xxxxxxxxxx>,Jakub Kicinski <kuba@xxxxxxxxxx>,Paolo Abeni <pabeni@xxxxxxxxxx>,netdev@xxxxxxxxxxxxxxx,linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: [PATCH net] net: phy: micrel: Fix potential shared PHC use-after-free>On Sat, Nov 07, 2026 at 02:54:37PM +0800, Guangshuo Li wrote:
>> The shared PHC outlives the first PHY's managed pin array and is not
>> unregistered before the package data is freed. Subsequent PHC operations
>> can therefore access released storage.
>>
>> Keep the pins at package scope and select a remaining PHY for register
>> access when a member leaves. Unregister the clock before releasing its
>> storage on the last member's exit. Pair each member's registration with
>> cleanup that also runs on probe failure, and serialize clock access with
>> member removal.
>
>You fix looks overly complicated. Ugly.
>
>Try looking at it from a different direction.
>
>.probe() and .remove() should be opposites of each other. What happens
>if you do that?
>
> Andrew
>
>---
>pw-bot: cr
>
On LAN8814, one PHY registers the shared PHC and owns its pin array.
If that PHY unregisters the clock in .remove(), the clock goes away
before the pins are freed. If another port is still bound, it loses
access to the PHC. I added the handoff in v1 to keep the clock
available in that case.
I'll rework this around the PHY that registered the clock. I'll check
how the remaining ports report the PHC after that PHY unbinds, and
what happens if it binds again while another port is still up.
Thanks,
Guangshuo