Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - netphy将 phy_config_inband() 锁定职责传输至 phylink 问题描述 =================== Lockdep 报告 &pl-> 之间可能的循环锁定依赖关系 (AB/BA) state_mutex 和 &phy->lock如下。 phylink_resolve() // 获取 &pl->state_mutex -> phylink_major_config() -> phy_config_inband() // 获取 &pl->phydev->lock 而 &pl->state_mutex 和 &pl->phydev->lock 拥有的所有其他调用站点锁定方案反转。在其他所有位置在顶层获取 &pl->phydev->lock而在较低级别获取 &pl->state_mutex。phylink_bringup_phy() 是一个明显的示例。异常值是新引入的 phy_config_inband()，正确的是现有锁定顺序。要了解为什么反之亦然，只需考虑由 PHY 状态机调用的 phylink_phy_change()即来自 PHY 设备的 phy->phy_link_change() 虚拟方法的 phylink 回调就足够了。 phy_link_up() 和 phy_link_down()即 phylink_phy_change() 的间接调用程序会通过已获得的 &phydev->lock 进行调用。然后phylink_phy_change() 获取其自己的 &pl->state_mutex以序列化对其 pl->phy_state 和 pl->link_config 进行的更改。因此 &pl->state_mutex 和 &phydev->lock 的所有其他实例必须与此顺序一致。问题影响 ============== 我认为如果导致 phy_config_inband() 调用的现有 phylink_resolve() 线程与 phy_link_up() 调用并发则内核存在严重的死锁风险phy_link_down() 调用将对 phylink_phy_change() 中 &pl->state_mutex 进行死锁。实际上影响可能会受到介质自动协商协议速度较慢的限制这使得在检测到新的自动协商协议时当前状态不太可能仍然处于未解决状态但我认为问题仍然存在。尽管如此该问题是在使用 lockdep 时发现的。建议的解决方案 ================= 实际上说phy_config_inband() 取得 phydev->lock 的要求必须传输至调用程序phylink 是唯一的调用程序。对于发生这种情况的情况，在获取 &pl->state_mutex 之前它必须一直向上冒。解决方案详细信息、注意事项、注释 ======================================= 这是 phy_config_inband（ ) 调用图sfp_upstream_ops ::
    connect_phy() | connect_phy() | connect_phy() | connect_phy() | connect_phy() | connect_phy() | connect_phy() | connect_phy() v phylink_sfp_connect_phy() | phylink_sfp_connect_phy() v phylink_sfp_config_phy() | phylink_sfp_config_phy() | sfp_upstream_ops ::
    module_insert() | module_insert() | module_insert() | module_insert() | | v | phylink_sfp_module_insert() | phylink_sfp_module_insert() | phylink_sfp_module_insert() | phylink_sfp_module_insert() | phylink_sfp_module_insert() | | | sfp_upstream_ops :: module_start() | sfp_upstream_ops | | | | v | | phylink_sfp_module_start() | phylink_sfp_module_start() | phylink_sfp_module_start() | phylink_sfp_module_start() | | | vv | phylink_sfp_config_Optical() phylink_start() | phylink_sfp_config_optical() | | | phylink_resume() 和 vv | phylink_resume() | phylink_sfp_set_config() | phylink_sfp_set_config() | phylink_sfp_set_config() | | vvv phylink_mac_initial_config() | vvv phylink_mac_initial_config() | vvv phylink_mac_initial_config() phylink_resolve() | | phylink_ethtool_ksettings_set() vvv phylink_major_config() | phylink_ethtool_ksettings_set() v phy_config_inband() phylink_major_config() 调用程序 #1phylink_mac_initial_config() 不会其调用程序获取 &pl->state_mutex。它必须在调用 phylink_major_config() 之前获取 &pl->phydev->lock。
    phylink_major_config() 调用程序 #2phylink_resolve() 获取 &pl->state_mutex因此也需要获取 &pl->phydev->lock。 phylink_major_config() 调用程序 #3phylink_ethtool_ksettings_set() 完全无关因为它仅调用 ---truncated--- (CVE-2025-39915)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2025-39915

medium Nessus 插件 ID 269680

版本 1.12