« Volver al listado

CVE-2025-39915

Estado: ModificadaMedia (5.5)—

In the Linux kernel, the following vulnerability has been resolved:

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().

Leer descripción completaMostrar menos

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:

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---

Detalles técnicos trazas, registros y código del informe original
                          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()

CVSS

Probabilidad de explotación (EPSS)

EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).

Tecnologías afectadas (1)

Linux — Linux Kernel

CWE

Referencias

JSON original (NVD)

Mostrar
{
  "id": "CVE-2025-39915",
  "cveTags": [],
  "metrics": {
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2025-39915",
          "role": "CISA Coordinator",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "version": "2.0.3",
          "timestamp": "2026-01-14T17:42:55.510925Z"
        }
      }
    ],
    "cvssMetricV31": [
      {
        "type": "Primary",
        "source": "nvd@nist.gov",
        "cvssData": {
          "scope": "UNCHANGED",
          "version": "3.1",
          "baseScore": 5.5,
          "attackVector": "LOCAL",
          "baseSeverity": "MEDIUM",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "integrityImpact": "NONE",
          "userInteraction": "NONE",
          "attackComplexity": "LOW",
          "availabilityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "confidentialityImpact": "NONE"
        },
        "impactScore": 3.6,
        "exploitabilityScore": 1.8
      },
      {
        "type": "Secondary",
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "cvssData": {
          "scope": "UNCHANGED",
          "version": "3.1",
          "baseScore": 5.5,
          "attackVector": "LOCAL",
          "baseSeverity": "MEDIUM",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "integrityImpact": "NONE",
          "userInteraction": "NONE",
          "attackComplexity": "LOW",
          "availabilityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "confidentialityImpact": "NONE"
        },
        "impactScore": 3.6,
        "exploitabilityScore": 1.8
      }
    ]
  },
  "affected": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "affectedData": [
        {
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "product": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5fd0f1a02e750e2db4038dee60edea669ce5aab1",
              "lessThan": "052ac41c379c8b87629808be612a482b2d0ae283",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "5fd0f1a02e750e2db4038dee60edea669ce5aab1",
              "lessThan": "e2a10daba84968f6b5777d150985fd7d6abc9c84",
              "versionType": "git"
            }
          ],
          "programFiles": [
            "drivers/net/phy/phy.c",
            "drivers/net/phy/phylink.c"
          ],
          "defaultStatus": "unaffected"
        },
        {
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "product": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.14"
            },
            {
              "status": "unaffected",
              "version": "0",
              "lessThan": "6.14",
              "versionType": "semver"
            },
            {
              "status": "unaffected",
              "version": "6.16.8",
              "versionType": "semver",
              "lessThanOrEqual": "6.16.*"
            },
            {
              "status": "unaffected",
              "version": "6.17",
              "versionType": "original_commit_for_fix",
              "lessThanOrEqual": "*"
            }
          ],
          "programFiles": [
            "drivers/net/phy/phy.c",
            "drivers/net/phy/phylink.c"
          ],
          "defaultStatus": "affected"
        }
      ]
    }
  ],
  "published": "2025-10-01T08:15:34.647",
  "references": [
    {
      "url": "https://git.kernel.org/stable/c/052ac41c379c8b87629808be612a482b2d0ae283",
      "tags": [
        "Patch"
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/e2a10daba84968f6b5777d150985fd7d6abc9c84",
      "tags": [
        "Patch"
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "type": "Primary",
      "source": "nvd@nist.gov",
      "description": [
        {
          "lang": "en",
          "value": "CWE-667"
        }
      ]
    },
    {
      "type": "Secondary",
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "description": [
        {
          "lang": "en",
          "value": "CWE-667"
        }
      ]
    }
  ],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: transfer phy_config_inband() locking responsibility to phylink\n\nProblem description\n===================\n\nLockdep reports a possible circular locking dependency (AB/BA) between\n&pl->state_mutex and &phy->lock, as follows.\n\nphylink_resolve() // acquires &pl->state_mutex\n-> phylink_major_config()\n   -> phy_config_inband() // acquires &pl->phydev->lock\n\nwhereas all the other call sites where &pl->state_mutex and\n&pl->phydev->lock have the locking scheme reversed. Everywhere else,\n&pl->phydev->lock is acquired at the top level, and &pl->state_mutex at\nthe lower level. A clear example is phylink_bringup_phy().\n\nThe outlier is the newly introduced phy_config_inband() and the existing\nlock order is the correct one. To understand why it cannot be the other\nway around, it is sufficient to consider phylink_phy_change(), phylink's\ncallback from the PHY device's phy->phy_link_change() virtual method,\ninvoked by the PHY state machine.\n\nphy_link_up() and phy_link_down(), the (indirect) callers of\nphylink_phy_change(), are called with &phydev->lock acquired.\nThen phylink_phy_change() acquires its own &pl->state_mutex, to\nserialize changes made to its pl->phy_state and pl->link_config.\nSo all other instances of &pl->state_mutex and &phydev->lock must be\nconsistent with this order.\n\nProblem impact\n==============\n\nI think the kernel runs a serious deadlock risk if an existing\nphylink_resolve() thread, which results in a phy_config_inband() call,\nis concurrent with a phy_link_up() or phy_link_down() call, which will\ndeadlock on &pl->state_mutex in phylink_phy_change(). Practically\nspeaking, the impact may be limited by the slow speed of the medium\nauto-negotiation protocol, which makes it unlikely for the current state\nto still be unresolved when a new one is detected, but I think the\nproblem is there. Nonetheless, the problem was discovered using lockdep.\n\nProposed solution\n=================\n\nPractically speaking, the phy_config_inband() requirement of having\nphydev->lock acquired must transfer to the caller (phylink is the only\ncaller). There, it must bubble up until immediately before\n&pl->state_mutex is acquired, for the cases where that takes place.\n\nSolution details, considerations, notes\n=======================================\n\nThis is the phy_config_inband() call graph:\n\n                          sfp_upstream_ops :: connect_phy()\n                          |\n                          v\n                          phylink_sfp_connect_phy()\n                          |\n                          v\n                          phylink_sfp_config_phy()\n                          |\n                          |   sfp_upstream_ops :: module_insert()\n                          |   |\n                          |   v\n                          |   phylink_sfp_module_insert()\n                          |   |\n                          |   |   sfp_upstream_ops :: module_start()\n                          |   |   |\n                          |   |   v\n                          |   |   phylink_sfp_module_start()\n                          |   |   |\n                          |   v   v\n                          |   phylink_sfp_config_optical()\n phylink_start()          |   |\n   |   phylink_resume()   v   v\n   |   |  phylink_sfp_set_config()\n   |   |  |\n   v   v  v\n phylink_mac_initial_config()\n   |   phylink_resolve()\n   |   |  phylink_ethtool_ksettings_set()\n   v   v  v\n   phylink_major_config()\n            |\n            v\n    phy_config_inband()\n\nphylink_major_config() caller #1, phylink_mac_initial_config(), does not\nacquire &pl->state_mutex nor do its callers. It must acquire\n&pl->phydev->lock prior to calling phylink_major_config().\n\nphylink_major_config() caller #2, phylink_resolve() acquires\n&pl->state_mutex, thus also needs to acquire &pl->phydev->lock.\n\nphylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is\ncompletely uninteresting, because it only call\n---truncated---"
    }
  ],
  "lastModified": "2026-06-17T09:18:49.207",
  "configurations": [
    {
      "nodes": [
        {
          "negate": false,
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "F6C3723D-6863-4401-AC08-FEB7AB987047",
              "versionEndExcluding": "6.16.8",
              "versionStartIncluding": "6.14"
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc1:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "327D22EF-390B-454C-BD31-2ED23C998A1C"
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc2:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "C730CD9A-D969-4A8E-9522-162AAF7C0EE9"
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc3:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "39982C4B-716E-4B2F-8196-FA301F47807D"
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc4:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "340BEEA9-D70D-4290-B502-FBB1032353B1"
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc5:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "47E4C5C0-079F-4838-971B-8C503D48FCC2"
            }
          ],
          "operator": "OR"
        }
      ]
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}