KEVWire

Security intelligence, with context.

Response snapshot Oct 30, 2026, 17:36 UTC

Back to the wire
Permalink
VulnerabilityCVE-2025-71152

Linux kernel: net: dsa: properly keep track of conduit reference

In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense.

At a glance

Exploited
Not known
Severity
7.8 High (CVSS 3.1)
Chance of exploitation
0.1% in the next 30 days
Sources
1 source

What to do

Check the vendor advisory for affected versions and fixes.

Read NVD CVE-2025-71152 (opens a new tab)

What happened

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

net: dsa: properly keep track of conduit reference

Problem description -------------------

DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense.

Continue reading

There are two distinct problems.

1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists.

With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command "before" and "after" applying this patch:

(unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind

we see these lines in the output diff which appear only with the patch applied:

kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)

2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly).

What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()).

Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it.

So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference.

Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal"), and the cpu_dp->conduit pointers remain valid.

I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes.

We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear.

We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed.

As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself.

History and blame attribution -----------------------------

The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct.

We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---

Scores and how they were measured

CVSS base severity

7.8

Version 3.1As of

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Measurement source (opens a new tab)

How bad it is if exploited. Not a prediction of exploitation or proof you are exposed.

EPSS probability

0.1%

Scored Percentile 3.7%

Model and measurement source (opens a new tab)

A model's estimate of exploitation in the next 30 days, not certainty or your own risk.

Related technology

Sources

  1. Primary source

    NVD CVE-2025-71152 (opens a new tab)

    NVD record: description, CVSS (the CNA score is preferred), affected products, and publication date. Not evidence of exploitation.

    Published Checked

  2. Primary source

    NVD CVE API 2.0 (opens a new tab)

    The NVD API page that supplied this CVE record.

    Published Date not suppliedChecked

  3. Primary source

    NVD CVE API 2.0 (opens a new tab)

    The NVD API page that supplied this CVE record.

    Published Date not suppliedChecked

  4. Primary source

    NVD CVE API 2.0 (opens a new tab)

    The NVD API page that supplied this CVE record.

    Published Date not suppliedChecked

  5. Primary source

    FIRST measured EPSS score (opens a new tab)

    Measured EPSS probability and percentile for CVE-2025-71152, scored 2026-10-30. This is a model estimate, not proof of exposure.

    Published Checked

Cite this record

For factual claims, cite the primary sources above; cite KEVWire for its compilation, dates, and classifications.

APA

KEVWire. (2026, October 30). Linux kernel: net: dsa: properly keep track of conduit reference (CVE-2025-71152). https://kevwire.com/record/CVE-2025-71152

MLA

"Linux kernel: net: dsa: properly keep track of conduit reference (CVE-2025-71152)." KEVWire, 30 Oct. 2026, kevwire.com/record/CVE-2025-71152.

Chicago

KEVWire. "Linux kernel: net: dsa: properly keep track of conduit reference (CVE-2025-71152)." Last modified October 30, 2026. https://kevwire.com/record/CVE-2025-71152.

Evidence summary (plain text)

Linux kernel: net: dsa: properly keep track of conduit reference (Jan 23, 2026).
In the Linux kernel, the following vulnerability has been resolved:

net: dsa: properly keep track of conduit reference

Problem description
-------------------

DSA has a mumbo-jumbo of reference handling of the conduit net device
and its kobject which, sadly, is just wrong and doesn't make sense.

There are two distinct problems.

1. The OF path, which uses of_find_net_device_by_node(), never releases
   the elevated refcount on the conduit's kobject.
CVSS 7.8 (version 3.1; evidence as of Oct 30, 2026; https://nvd.nist.gov/vuln/detail/CVE-2025-71152).
EPSS 0.1% for the following 30 days, scored Oct 30, 2026 (https://api.first.org/data/v1/epss?cve=CVE-2025-71152&date=2026-10-30).
Sources:
NVD CVE-2025-71152: https://nvd.nist.gov/vuln/detail/CVE-2025-71152
NVD CVE API 2.0: https://services.nvd.nist.gov/rest/json/cves/2.0?lastModStartDate=2026-10-30T13:06:45.042Z&lastModEndDate=2026-10-30T14:50:57.069Z&resultsPerPage=500&startIndex=0
NVD CVE API 2.0: https://services.nvd.nist.gov/rest/json/cves/2.0?lastModStartDate=2026-10-30T12:22:16.957Z&lastModEndDate=2026-10-30T14:05:57.373Z&resultsPerPage=500&startIndex=0
NVD CVE API 2.0: https://services.nvd.nist.gov/rest/json/cves/2.0?lastModStartDate=2026-10-30T11:45:59.009Z&lastModEndDate=2026-10-30T13:20:57.281Z&resultsPerPage=500&startIndex=0
FIRST measured EPSS score: https://api.first.org/data/v1/epss?cve=CVE-2025-71152&date=2026-10-30
Record ID: CVE-2025-71152.
Record origin: Ingested record.
AI evidence: Not assessed.
Known exploitation: Not assessed.
Zero-day status: Not assessed. KEV membership alone does not establish zero-day status.
About this data

This record was ingested from a data source. Retrieved: Oct 30, 2026, 14:52 UTC. Ingestion is not an independent editorial investigation.

NVD status: Modified. Publication in the NVD is not evidence of exploitation.

A CISA KEV listing documents known exploitation, not necessarily a zero-day; absence from the catalog does not prove a vulnerability has never been exploited.

Technology tags indicate possible relevance, not verified exposure. Confirm the affected product, version, and configuration against your own inventory; KEVWire does not scan your systems.

A personal reading checklist on this device, not verified remediation.

Record JSON

Your account

Email alerts

Email alerts are coming as part of KEVWire Premium: join the waitlist. To follow your stack today, use its RSS feed, which honors your filters, or connect an AI agent through the API.

Suggest an improvement

Ideas, missing sources, corrections, and bugs are all welcome. No account needed. Suggestions are reviewed by a person before anything changes.

Record details

Record detail