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.

Detections

Analytics

Linux Distros Unpatched Vulnerability : CVE-2025-39915

medium Nessus Plugin ID 269680

Version 1.9

Version 1.8

Version 1.7

Version 1.6

Version 1.5

Version 1.3

Version 1.2

Version 1.9 Jan 31, 2026, 11:07 AM Plugin metadata Plugin Feed: 202601311107
Version 1.8 Jan 30, 2026, 10:33 PM Detection (updated detection logic) Plugin metadata Plugin Feed: 202601302233
Version 1.7 Jan 21, 2026, 5:00 PM Detection (updated detection logic) Plugin metadata Plugin Feed: 202601211700
Version 1.6 Jan 10, 2026, 7:58 PM CVSS metrics ("CVSSv3 score" set to 5.5) CVSS metrics ("CVSSv3 vector" set to "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H") Detection (updated detection logic) Plugin metadata Plugin Feed: 202601101958
Version 1.5 Nov 26, 2025, 1:15 PM Detection (updated detection logic) Plugin metadata Plugin Feed: 202511261315
Version 1.3 Oct 27, 2025, 3:15 PM CVSS temporal metrics ("CVSSv2 temporal vector" set to "CVSS2#E:U/RL:U/RC:C") CVSS temporal metrics ("CVSSv3 temporal vector" set to "CVSS:3.0/E:U/RL:U/RC:C") Detection (updated detection logic) Plugin metadata Plugin Feed: 202510271515
Version 1.2 Oct 14, 2025, 8:03 AM CVSS metrics ("CVSSv2 score" set to 4.9) CVSS metrics ("CVSSv2 vector" set to "CVSS2#AV:L/AC:L/Au:N/C:N/I:N/A:C") CVSSv2 severity (based on CVE-2025-39915, severity increased from "Low" to "Medium") Detection (updated detection logic) Plugin metadata Plugin Feed: 202510140803