The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - net: phy: transfer phy_config_inband() locking responsibility to phylink Problem description     =================== Lockdep reports a possible circular locking dependency (AB/BA) between     &pl->state_mutex and &phy->lock, as follows. phylink_resolve() // acquires &pl->state_mutex ->     phylink_major_config() -> phy_config_inband() // acquires &pl->phydev->lock whereas all the other call     sites where &pl->state_mutex and &pl->phydev->lock have the locking scheme reversed. Everywhere else,     &pl->phydev->lock is acquired at the top level, and &pl->state_mutex at the lower level. A clear example     is phylink_bringup_phy(). The outlier is the newly introduced phy_config_inband() and the existing lock     order is the correct one. To understand why it cannot be the other way around, it is sufficient to     consider phylink_phy_change(), phylink's callback from the PHY device's phy->phy_link_change() virtual     method, invoked by the PHY state machine. phy_link_up() and phy_link_down(), the (indirect) callers of     phylink_phy_change(), are called with &phydev->lock acquired. Then phylink_phy_change() acquires its own     &pl->state_mutex, to serialize changes made to its pl->phy_state and pl->link_config. So all other     instances of &pl->state_mutex and &phydev->lock must be consistent with this order. Problem impact     ============== I think the kernel runs a serious deadlock risk if an existing phylink_resolve() thread,     which results in a phy_config_inband() call, is concurrent with a phy_link_up() or phy_link_down() call,     which will deadlock on &pl->state_mutex in phylink_phy_change(). Practically speaking, the impact may be     limited by the slow speed of the medium auto-negotiation protocol, which makes it unlikely for the current     state to still be unresolved when a new one is detected, but I think the problem is there. Nonetheless,     the problem was discovered using lockdep. Proposed solution ================= Practically speaking, the     phy_config_inband() requirement of having phydev->lock acquired must transfer to the caller (phylink is     the only caller). There, it must bubble up until immediately before &pl->state_mutex is acquired, for the     cases where that takes place. Solution details, considerations, notes     ======================================= This is the phy_config_inband() call graph: sfp_upstream_ops ::
    connect_phy() | v phylink_sfp_connect_phy() | v phylink_sfp_config_phy() | | sfp_upstream_ops ::
    module_insert() | | | v | phylink_sfp_module_insert() | | | | sfp_upstream_ops :: module_start() | | | | |     v | | phylink_sfp_module_start() | | | | v v | phylink_sfp_config_optical() phylink_start() | | |     phylink_resume() v v | | phylink_sfp_set_config() | | | v v v phylink_mac_initial_config() |     phylink_resolve() | | phylink_ethtool_ksettings_set() v v v phylink_major_config() | v phy_config_inband()     phylink_major_config() caller #1, phylink_mac_initial_config(), does not acquire &pl->state_mutex nor do     its callers. It must acquire &pl->phydev->lock prior to calling phylink_major_config().
    phylink_major_config() caller #2, phylink_resolve() acquires &pl->state_mutex, thus also needs to acquire     &pl->phydev->lock. phylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is completely     uninteresting, because it only call ---truncated--- (CVE-2025-39915)

Note that Nessus relies on the presence of the package as reported by the vendor.

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - netphy問題の説明 =================================================================================================================================================================================================== 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 状態マシンによって呼び出される、PHY デバイスの phy->phy_link_change() 仮想メソッドからの phylink のコールバックである phylink_phy_change() を検討するだけで十分です。 phylink_phy_change() の間接呼び出し元である phy_link_up() および phy_link_down() は、&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_up() と同時実行されると、カーネルは重大なデッドロックリスクを実行すると考えられます。 phy_link_down() 呼び出し。これにより、phylink_phy_change() の &pl->state_mutex でデッドロックが発生します。実用上、この影響は、自動ネゴシエーションプロトコルの低速によって制限される可能性があります。これにより、新しい状態が検出されたときに現在の状態がまだ解決されない可能性がありますが、問題があると考えます。それにも関わらず、lockdep を使用して問題が発見されました。提案されたソリューション ================== 実際に、phydev->lock を取得するための phy_config_inband() の要件は、呼び出し元に転送する必要がありますphylink のみです。ここでは、&pl->state_mutex が発生する場合、取得の直前までバブルアップする必要があります。ソリューションの詳細、考慮事項、注記 =================================== これは phy_config_inband( ) graphsfp_upstream_ops :
    connect_phy() | v phylink_sfp_connect_phy() | v phylink_sfp_config_phy() | | sfp_upstream_ops
    module_insert() | | | v | phylink_sfp_module_insert() | | | | sfp_upstream_ops module_start() | | | | | v | | phylink_sfp_module_start() | | | | vv | phylink_sfp_config_optical() phylink_start() | | | phylink_resume() vv | | phylink_sfp_set_config() | | | vvv phylink_mac_initial_config() | phylink_resolve() | | phylink_ethtool_ksettings_set() vvv phylink_major_config() | v phy_config_inband() phylink_major_config() 呼び出し元 #1、phylink_mac_initial_config() は、&pl->state_mutex を取得せず、その呼び出し元も行いません。phylink_major_config() を呼び出す前に &pl->phydev->lock を取得する必要があります。
    phylink_major_config() 呼び出し元 #2、phylink_resolve() は &pl->state_mutex を取得するため、&pl->phydev->lock も取得する必要があります。 phylink_major_config() 呼び出し元 #3、phylink_ethtool_ksettings_set() は呼び出し ---truncated---CVE-2025-39915]

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

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/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()而現有的鎖定順序是正確的。若要了解反之無法做到的原因只需考慮 phylink_phy_change()即來自 PHY 裝置之 phy->phy_link_change() 虛擬方法的 phylink 回呼由 PHY 狀態機器叫用。在取得 &phydev->lock 的情況下呼叫 phy_link_up() 和 phy_link_down()這是 phylink_phy_change() 的 (間接) 呼叫者。然後 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 時發現的。建議的解決方案 ================= 實際上說來必須將取得 phydev->lock 的 phy_config_inband() 需求傳輸給呼叫者 (phylink 是唯一的呼叫者)。在此情況下其必須冒泡泡直到即將取得 &pl->state_mutex 為止。解決方案詳細資料、注意事項、注意事項 ======================================= 這是 phy_config_inband( ) call graphsfp_upstream_ops ::
    connect_phy() | v phylink_sfp_connect_phy() | v phylink_sfp_config_phy() | | sfp_upstream_ops ::
    module_insert() | | | v | phylink_sfp_module_insert() | | | | sfp_upstream_ops :: module_start() | | | | | v | | phylink_sfp_module_start() | | | | vv | phylink_sfp_config_optical() phylink_start() | | | phylink_resume() vv | | phylink_sfp_set_config() | | | vvv phylink_mac_initial_config() | phylink_resolve() | | phylink_ethtool_ksettings_set() vvv phylink_major_config() | v phy_config_inband() phylink_major_config() 呼叫者 #1、phylink_mac_initial_config() 未取得 &pl->state_mutex其呼叫者亦然。其必須先取得 &pl->phydev->lock 再呼叫 phylink_major_config()。
    phylink_major_config() 呼叫者 #2、phylink_resolve() 取得 &pl->state_mutex因此也需要取得 &pl->phydev->lock。 phylink_major_config() caller #3phylink_ethtool_ksettings_set() 完全無關因為它只會呼叫 ---truncated--- (CVE-2025-39915)

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

ID	名前	製品	ファミリー	公開日	更新日	深刻度
269680	Linux Distros Unpatched Vulnerability : CVE-2025-39915	Nessus	Misc.	2025/10/8	2025/10/8	medium
269680	Linux Distros のパッチ未適用の脆弱性: CVE-2025-39915	Nessus	Misc.	2025/10/8	2025/10/8	medium
269680	Linux Distros 未修补的漏洞：CVE-2025-39915	Nessus	Misc.	2025/10/8	2025/10/8	medium
269680	Linux Distros 未修補的弱點：CVE-2025-39915	Nessus	Misc.	2025/10/8	2025/10/8	medium

検出

プラグインの検索

medium

medium

medium

medium