cbcvebase.
CVE-2025-37945
published 2025-05-20

CVE-2025-37945: In the Linux kernel, the following vulnerability has been resolved: net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY DSA…

PriorityP421medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.17%
6.2th percentile
In the Linux kernel, the following vulnerability has been resolved: net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY DSA has 2 kinds of drivers: 1. Those who call dsa_switch_suspend() and dsa_switch_resume() from their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz 2. Those who don't: all others. The above methods should be optional. For type 1, dsa_switch_suspend() calls dsa_user_suspend() -> phylink_stop(), and dsa_switch_resume() calls dsa_user_resume() -> phylink_start(). These seem good candidates for setting mac_managed_pm = true because that is essentially its definition [1], but that does not seem to be the biggest problem for now, and is not what this change focuses on. Talking strictly about the 2nd category of DSA drivers here (which do not have MAC managed PM, meaning that for their attached PHYs, mdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full), I have noticed that the following warning from mdio_bus_phy_resume() is triggered: WARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY && phydev->state != PHY_UP); because the PHY state machine is running. It's running as a result of a previous dsa_user_open() -> ... -> phylink_start() -> phy_start() having been initiated by the user. The previous mdio_bus_phy_suspend() was supposed to have called phy_stop_machine(), but it didn't. So this is why the PHY is in state PHY_NOLINK by the time mdio_bus_phy_resume() runs. mdio_bus_phy_suspend() did not call phy_stop_machine() because for phylink, the phydev->adjust_link function pointer is NULL. This seems a technicality introduced by commit fddd91016d16 ("phylib: fix PAL state machine restart on resume"). That commit was written before phylink existed, and was intended to avoid crashing with consumer drivers which don't use the PHY state machine - phylink always does, when using a PHY. But phylink itself has historically not been developed with suspend/resume in mind, and apparently

Affected

39 ranges· showing 25
VendorProductVersion rangeFixed in
debianlinux< linux 6.12.25-1 (forky)linux 6.12.25-1 (forky)
linuxlinux
linuxlinux
linuxlinux
linuxlinux>= 5.15.63 < 5.165.16
linuxlinux>= 5.19.4 < 5.205.20
linuxlinux>= 744d23c71af39c7dc77ac7c3cac87ae86a181a85 < 17eef1e44883845b9567afc893dc41e004c08d6517eef1e44883845b9567afc893dc41e004c08d65
linuxlinux>= 744d23c71af39c7dc77ac7c3cac87ae86a181a85 < 043aa41c43f8cb9cce75367ea07895ce68b5abb0043aa41c43f8cb9cce75367ea07895ce68b5abb0
linuxlinux>= 744d23c71af39c7dc77ac7c3cac87ae86a181a85 < a6ed6f8ec81b8ca7100dcd9e62bdbc0dff1b2259a6ed6f8ec81b8ca7100dcd9e62bdbc0dff1b2259
linuxlinux>= 744d23c71af39c7dc77ac7c3cac87ae86a181a85 < 54e5d00a8de6c13f6c01a94ed48025e882cd15f754e5d00a8de6c13f6c01a94ed48025e882cd15f7
linuxlinux>= 744d23c71af39c7dc77ac7c3cac87ae86a181a85 < bd4037d51d3f6667636a1383e78e48a5b7b60755bd4037d51d3f6667636a1383e78e48a5b7b60755
linuxlinux>= 744d23c71af39c7dc77ac7c3cac87ae86a181a85 < fc75ea20ffb452652f0d4033f38fe88d7cfdae35fc75ea20ffb452652f0d4033f38fe88d7cfdae35
linuxlinux_kernel
linuxlinux_kernel>= 0 < 6.12.25-16.12.25-1
linuxlinux_kernel>= 0 < 6.12.25-16.12.25-1
linuxlinux_kernel>= 0 < 6.8.0-100.1006.8.0-100.100
linuxlinux_kernel>= 0 < 6.14.0-22.226.14.0-22.22
linuxlinux_kernel>= 5.15.63 < 5.165.16
linuxlinux_kernel>= 5.19.4 < 6.12.246.12.24
linuxlinux_kernel>= 6.13 < 6.13.126.13.12
linuxlinux_kernel>= 6.14 < 6.14.36.14.3
msrcazl3_kernel_6.6.112.1-2_on_azure_linux_3.0
msrcazl3_kernel_6.6.116.1-1_on_azure_linux_3.0
msrcazl3_kernel_6.6.117.1-1_on_azure_linux_3.0
msrcazl3_kernel_6.6.119.3-1_on_azure_linux_3.0

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_msrc5.5MEDIUM
vendor_redhat5.5MEDIUM
vendor_ubuntu3.2LOW
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.