CVE-2025-39915 (GCVE-0-2025-39915)

Vulnerability from cvelistv5 – Published: 2025-10-01 07:44 – Updated: 2026-05-11 21:38
VLAI
Title
net: phy: transfer phy_config_inband() locking responsibility to phylink
Summary
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(). 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---
Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CWE
Assigner
References
Impacted products
Vendor Product Version
Linux Linux Affected: 5fd0f1a02e750e2db4038dee60edea669ce5aab1 , < 052ac41c379c8b87629808be612a482b2d0ae283 (git)
Affected: 5fd0f1a02e750e2db4038dee60edea669ce5aab1 , < e2a10daba84968f6b5777d150985fd7d6abc9c84 (git)
Create a notification for this product.
Linux Linux Affected: 6.14
Unaffected: 0 , < 6.14 (semver)
Unaffected: 6.16.8 , ≤ 6.16.* (semver)
Unaffected: 6.17 , ≤ * (original_commit_for_fix)
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "LOCAL",
              "availabilityImpact": "HIGH",
              "baseScore": 5.5,
              "baseSeverity": "MEDIUM",
              "confidentialityImpact": "NONE",
              "integrityImpact": "NONE",
              "privilegesRequired": "LOW",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2025-39915",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-01-14T17:42:55.510925Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-667",
                "description": "CWE-667 Improper Locking",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-01-14T17:52:47.502Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/phy/phy.c",
            "drivers/net/phy/phylink.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "052ac41c379c8b87629808be612a482b2d0ae283",
              "status": "affected",
              "version": "5fd0f1a02e750e2db4038dee60edea669ce5aab1",
              "versionType": "git"
            },
            {
              "lessThan": "e2a10daba84968f6b5777d150985fd7d6abc9c84",
              "status": "affected",
              "version": "5fd0f1a02e750e2db4038dee60edea669ce5aab1",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/phy/phy.c",
            "drivers/net/phy/phylink.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.14"
            },
            {
              "lessThan": "6.14",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.16.*",
              "status": "unaffected",
              "version": "6.16.8",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.17",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.16.8",
                  "versionStartIncluding": "6.14",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.17",
                  "versionStartIncluding": "6.14",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "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\u0026pl-\u003estate_mutex and \u0026phy-\u003elock, as follows.\n\nphylink_resolve() // acquires \u0026pl-\u003estate_mutex\n-\u003e phylink_major_config()\n   -\u003e phy_config_inband() // acquires \u0026pl-\u003ephydev-\u003elock\n\nwhereas all the other call sites where \u0026pl-\u003estate_mutex and\n\u0026pl-\u003ephydev-\u003elock have the locking scheme reversed. Everywhere else,\n\u0026pl-\u003ephydev-\u003elock is acquired at the top level, and \u0026pl-\u003estate_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\u0027s\ncallback from the PHY device\u0027s phy-\u003ephy_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 \u0026phydev-\u003elock acquired.\nThen phylink_phy_change() acquires its own \u0026pl-\u003estate_mutex, to\nserialize changes made to its pl-\u003ephy_state and pl-\u003elink_config.\nSo all other instances of \u0026pl-\u003estate_mutex and \u0026phydev-\u003elock 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 \u0026pl-\u003estate_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-\u003elock acquired must transfer to the caller (phylink is the only\ncaller). There, it must bubble up until immediately before\n\u0026pl-\u003estate_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 \u0026pl-\u003estate_mutex nor do its callers. It must acquire\n\u0026pl-\u003ephydev-\u003elock prior to calling phylink_major_config().\n\nphylink_major_config() caller #2, phylink_resolve() acquires\n\u0026pl-\u003estate_mutex, thus also needs to acquire \u0026pl-\u003ephydev-\u003elock.\n\nphylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is\ncompletely uninteresting, because it only call\n---truncated---"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T21:38:52.462Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/052ac41c379c8b87629808be612a482b2d0ae283"
        },
        {
          "url": "https://git.kernel.org/stable/c/e2a10daba84968f6b5777d150985fd7d6abc9c84"
        }
      ],
      "title": "net: phy: transfer phy_config_inband() locking responsibility to phylink",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-39915",
    "datePublished": "2025-10-01T07:44:37.884Z",
    "dateReserved": "2025-04-16T07:20:57.147Z",
    "dateUpdated": "2026-05-11T21:38:52.462Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2025-39915",
      "date": "2026-05-26",
      "epss": "0.00015",
      "percentile": "0.03518"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-39915\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-10-01T08:15:34.647\",\"lastModified\":\"2026-01-14T18:16:39.857\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"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\u0026pl-\u003estate_mutex and \u0026phy-\u003elock, as follows.\\n\\nphylink_resolve() // acquires \u0026pl-\u003estate_mutex\\n-\u003e phylink_major_config()\\n   -\u003e phy_config_inband() // acquires \u0026pl-\u003ephydev-\u003elock\\n\\nwhereas all the other call sites where \u0026pl-\u003estate_mutex and\\n\u0026pl-\u003ephydev-\u003elock have the locking scheme reversed. Everywhere else,\\n\u0026pl-\u003ephydev-\u003elock is acquired at the top level, and \u0026pl-\u003estate_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\u0027s\\ncallback from the PHY device\u0027s phy-\u003ephy_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 \u0026phydev-\u003elock acquired.\\nThen phylink_phy_change() acquires its own \u0026pl-\u003estate_mutex, to\\nserialize changes made to its pl-\u003ephy_state and pl-\u003elink_config.\\nSo all other instances of \u0026pl-\u003estate_mutex and \u0026phydev-\u003elock 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 \u0026pl-\u003estate_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-\u003elock acquired must transfer to the caller (phylink is the only\\ncaller). There, it must bubble up until immediately before\\n\u0026pl-\u003estate_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 \u0026pl-\u003estate_mutex nor do its callers. It must acquire\\n\u0026pl-\u003ephydev-\u003elock prior to calling phylink_major_config().\\n\\nphylink_major_config() caller #2, phylink_resolve() acquires\\n\u0026pl-\u003estate_mutex, thus also needs to acquire \u0026pl-\u003ephydev-\u003elock.\\n\\nphylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is\\ncompletely uninteresting, because it only call\\n---truncated---\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6},{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-667\"}]},{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-667\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.14\",\"versionEndExcluding\":\"6.16.8\",\"matchCriteriaId\":\"F6C3723D-6863-4401-AC08-FEB7AB987047\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.17:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"327D22EF-390B-454C-BD31-2ED23C998A1C\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.17:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"C730CD9A-D969-4A8E-9522-162AAF7C0EE9\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.17:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"39982C4B-716E-4B2F-8196-FA301F47807D\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.17:rc4:*:*:*:*:*:*\",\"matchCriteriaId\":\"340BEEA9-D70D-4290-B502-FBB1032353B1\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.17:rc5:*:*:*:*:*:*\",\"matchCriteriaId\":\"47E4C5C0-079F-4838-971B-8C503D48FCC2\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/052ac41c379c8b87629808be612a482b2d0ae283\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/e2a10daba84968f6b5777d150985fd7d6abc9c84\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"cvssV3_1\": {\"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\"}}, {\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2025-39915\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-01-14T17:42:55.510925Z\"}}}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-667\", \"description\": \"CWE-667 Improper Locking\"}]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-01-14T17:42:51.612Z\"}}], \"cna\": {\"title\": \"net: phy: transfer phy_config_inband() locking responsibility to phylink\", \"affected\": [{\"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\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/052ac41c379c8b87629808be612a482b2d0ae283\"}, {\"url\": \"https://git.kernel.org/stable/c/e2a10daba84968f6b5777d150985fd7d6abc9c84\"}], \"x_generator\": {\"engine\": \"bippy-1.2.0\"}, \"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\u0026pl-\u003estate_mutex and \u0026phy-\u003elock, as follows.\\n\\nphylink_resolve() // acquires \u0026pl-\u003estate_mutex\\n-\u003e phylink_major_config()\\n   -\u003e phy_config_inband() // acquires \u0026pl-\u003ephydev-\u003elock\\n\\nwhereas all the other call sites where \u0026pl-\u003estate_mutex and\\n\u0026pl-\u003ephydev-\u003elock have the locking scheme reversed. Everywhere else,\\n\u0026pl-\u003ephydev-\u003elock is acquired at the top level, and \u0026pl-\u003estate_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\u0027s\\ncallback from the PHY device\u0027s phy-\u003ephy_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 \u0026phydev-\u003elock acquired.\\nThen phylink_phy_change() acquires its own \u0026pl-\u003estate_mutex, to\\nserialize changes made to its pl-\u003ephy_state and pl-\u003elink_config.\\nSo all other instances of \u0026pl-\u003estate_mutex and \u0026phydev-\u003elock 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 \u0026pl-\u003estate_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-\u003elock acquired must transfer to the caller (phylink is the only\\ncaller). There, it must bubble up until immediately before\\n\u0026pl-\u003estate_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 \u0026pl-\u003estate_mutex nor do its callers. It must acquire\\n\u0026pl-\u003ephydev-\u003elock prior to calling phylink_major_config().\\n\\nphylink_major_config() caller #2, phylink_resolve() acquires\\n\u0026pl-\u003estate_mutex, thus also needs to acquire \u0026pl-\u003ephydev-\u003elock.\\n\\nphylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is\\ncompletely uninteresting, because it only call\\n---truncated---\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.16.8\", \"versionStartIncluding\": \"6.14\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.17\", \"versionStartIncluding\": \"6.14\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2025-10-01T07:44:37.884Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2025-39915\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-01-14T17:52:47.502Z\", \"dateReserved\": \"2025-04-16T07:20:57.147Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2025-10-01T07:44:37.884Z\", \"assignerShortName\": \"Linux\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.