Description
In the Linux kernel, the following vulnerability has been resolved: net: phy: Don't register LEDs for genphy If a PHY has no driver, the genphy driver is probed/removed directly in phy_attach/detach. If the PHY's ofnode has an "leds" subnode, then the LEDs will be (un)registered when probing/removing the genphy driver. This could occur if the leds are for a non-generic driver that isn't loaded for whatever reason. Synchronously removing the PHY device in phy_detach leads to the following deadlock: rtnl_lock() ndo_close() ... phy_detach() phy_remove() phy_leds_unregister() led_classdev_unregister() led_trigger_set() netdev_trigger_deactivate() unregister_netdevice_notifier() rtnl_lock() There is a corresponding deadlock on the open/register side of things (and that one is reported by lockdep), but it requires a race while this one is deterministic. Generic PHYs do not support LEDs anyway, so don't bother registering them.
Affected products
Version statuses are supplied by the assigning organization. Consult the original record for detailed ranges and platform conditions.
Linux Linux
Default version status: unaffected
01e5b728e9e43ae444e0369695a5f72209906464 to < ec158d05eaa91b2809cab65f8068290e3c05ebddaffected01e5b728e9e43ae444e0369695a5f72209906464 to < fd6493533af9e5d73d0d42ff2a8ded978a701dc6affected01e5b728e9e43ae444e0369695a5f72209906464 to < 75e1b2079ef0653a2f7aa69be515d86b7faf1908affected01e5b728e9e43ae444e0369695a5f72209906464 to < f0f2b992d8185a0366be951685e08643aae17d6daffected
Linux Linux
Default version status: affected
6.4affected0 to < 6.4unaffected6.6.100 to ≤ 6.6.*unaffected6.12.40 to ≤ 6.12.*unaffected6.15.8 to ≤ 6.15.*unaffected6.16 to ≤ *unaffected