linux-cve-announce - CVE-2025-38537: net: phy: Don't register LEDs for genphy

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>] [day] [month] [year] [list]

Message-ID: <2025081657-CVE-2025-38537-180a@gregkh>
Date: Sat, 16 Aug 2025 13:14:08 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-38537: net: phy: Don't register LEDs for genphy

From: Greg Kroah-Hartman <gregkh@...nel.org>

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.

The Linux kernel CVE team has assigned CVE-2025-38537 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.4 with commit 01e5b728e9e43ae444e0369695a5f72209906464 and fixed in 6.6.100 with commit ec158d05eaa91b2809cab65f8068290e3c05ebdd
	Issue introduced in 6.4 with commit 01e5b728e9e43ae444e0369695a5f72209906464 and fixed in 6.12.40 with commit fd6493533af9e5d73d0d42ff2a8ded978a701dc6
	Issue introduced in 6.4 with commit 01e5b728e9e43ae444e0369695a5f72209906464 and fixed in 6.15.8 with commit 75e1b2079ef0653a2f7aa69be515d86b7faf1908
	Issue introduced in 6.4 with commit 01e5b728e9e43ae444e0369695a5f72209906464 and fixed in 6.16 with commit f0f2b992d8185a0366be951685e08643aae17d6d

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-38537
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/net/phy/phy_device.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/ec158d05eaa91b2809cab65f8068290e3c05ebdd
	https://git.kernel.org/stable/c/fd6493533af9e5d73d0d42ff2a8ded978a701dc6
	https://git.kernel.org/stable/c/75e1b2079ef0653a2f7aa69be515d86b7faf1908
	https://git.kernel.org/stable/c/f0f2b992d8185a0366be951685e08643aae17d6d