| From bippy-1.2.0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@kernel.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2025-37945: net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY |
| |
| Description |
| =========== |
| |
| 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 not tested too much in that |
| scenario, allowing this bug to exist unnoticed for so long. Plus, prior |
| to the WARN_ON(), it would have likely been invisible. |
| |
| This issue is not in fact restricted to type 2 DSA drivers (according to |
| the above ad-hoc classification), but can be extrapolated to any MAC |
| driver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where |
| the issue was reported. Assuming mac_managed_pm is set correctly, a |
| quick search indicates the following other drivers might be affected: |
| |
| $ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pm |
| drivers/net/ethernet/atheros/ag71xx.c |
| drivers/net/ethernet/microchip/sparx5/sparx5_main.c |
| drivers/net/ethernet/microchip/lan966x/lan966x_main.c |
| drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c |
| drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c |
| drivers/net/ethernet/freescale/dpaa/dpaa_eth.c |
| drivers/net/ethernet/freescale/ucc_geth.c |
| drivers/net/ethernet/freescale/enetc/enetc_pf_common.c |
| drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c |
| drivers/net/ethernet/marvell/mvneta.c |
| drivers/net/ethernet/marvell/prestera/prestera_main.c |
| drivers/net/ethernet/mediatek/mtk_eth_soc.c |
| drivers/net/ethernet/altera/altera_tse_main.c |
| drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c |
| drivers/net/ethernet/meta/fbnic/fbnic_phylink.c |
| drivers/net/ethernet/tehuti/tn40_phy.c |
| drivers/net/ethernet/mscc/ocelot_net.c |
| |
| Make the existing conditions dependent on the PHY device having a |
| phydev->phy_link_change() implementation equal to the default |
| phy_link_change() provided by phylib. Otherwise, we implicitly know that |
| the phydev has the phylink-provided phylink_phy_change() callback, and |
| when phylink is used, the PHY state machine always needs to be stopped/ |
| started on the suspend/resume path. The code is structured as such that |
| if phydev->phy_link_change() is absent, it is a matter of time until the |
| kernel will crash - no need to further complicate the test. |
| |
| Thus, for the situation where the PM is not managed by the MAC, we will |
| make the MDIO bus PM ops treat identically the phylink-controlled PHYs |
| with the phylib-controlled PHYs where an adjust_link() callback is |
| supplied. In both cases, the MDIO bus PM ops should stop and restart the |
| PHY state machine. |
| |
| [1] https://lore.kernel.org/netdev/Z-1tiW9zjcoFkhwc@shell.armlinux.org.uk/ |
| |
| The Linux kernel CVE team has assigned CVE-2025-37945 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 6.0 with commit 744d23c71af39c7dc77ac7c3cac87ae86a181a85 and fixed in 6.12.24 with commit a6ed6f8ec81b8ca7100dcd9e62bdbc0dff1b2259 |
| Issue introduced in 6.0 with commit 744d23c71af39c7dc77ac7c3cac87ae86a181a85 and fixed in 6.13.12 with commit 54e5d00a8de6c13f6c01a94ed48025e882cd15f7 |
| Issue introduced in 6.0 with commit 744d23c71af39c7dc77ac7c3cac87ae86a181a85 and fixed in 6.14.3 with commit bd4037d51d3f6667636a1383e78e48a5b7b60755 |
| Issue introduced in 6.0 with commit 744d23c71af39c7dc77ac7c3cac87ae86a181a85 and fixed in 6.15 with commit fc75ea20ffb452652f0d4033f38fe88d7cfdae35 |
| Issue introduced in 5.15.63 with commit 47ac7b2f6a1ffef76e55a9ec146881a36673284b |
| Issue introduced in 5.19.4 with commit 7dc0ed411de3450e75b2a9600b5742cbf0908167 |
| |
| 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-37945 |
| 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/a6ed6f8ec81b8ca7100dcd9e62bdbc0dff1b2259 |
| https://git.kernel.org/stable/c/54e5d00a8de6c13f6c01a94ed48025e882cd15f7 |
| https://git.kernel.org/stable/c/bd4037d51d3f6667636a1383e78e48a5b7b60755 |
| https://git.kernel.org/stable/c/fc75ea20ffb452652f0d4033f38fe88d7cfdae35 |
