Linux Kernel bis 6.18.3/6.19-rc3 Conduit Driver of_find_net_device_by_node Denial of Service

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
6.6$0-$5k0.00

Zusammenfassunginfo

In Linux Kernel bis 6.18.3/6.19-rc3 wurde eine Schwachstelle ausgemacht. Sie wurde als kritisch eingestuft. Es ist betroffen die Funktion of_find_net_device_by_node der Komponente Conduit Driver. Durch Manipulation mit unbekannten Daten kann eine Denial of Service-Schwachstelle ausgenutzt werden. Diese Schwachstelle wird als CVE-2025-71152 gehandelt. Es ist kein Exploit verfügbar. Es wird empfohlen, die betroffene Komponente zu aktualisieren.

Detailsinfo

Es wurde eine Schwachstelle in Linux Kernel bis 6.18.3/6.19-rc3 ausgemacht. Sie wurde als kritisch eingestuft. Es betrifft die Funktion of_find_net_device_by_node der Komponente Conduit Driver. Durch Manipulation mit einer unbekannten Eingabe kann eine Denial of Service-Schwachstelle ausgenutzt werden. Im Rahmen von CWE wurde eine Klassifizierung als CWE-911 vorgenommen. Die Auswirkungen sind bekannt für die Verfügbarkeit. Die Zusammenfassung von CVE lautet:

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

Das Advisory findet sich auf git.kernel.org. Die Identifikation der Schwachstelle wird seit dem 13.01.2026 mit CVE-2025-71152 vorgenommen. Es sind zwar technische Details, jedoch kein verfügbarer Exploit zur Schwachstelle bekannt.

Für den Vulnerability Scanner Nessus wurde ein Plugin mit der ID 296382 (Linux Distros Unpatched Vulnerability : CVE-2025-71152) herausgegeben, womit die Existenz der Schwachstelle geprüft werden kann.

Ein Aktualisieren auf die Version 6.18.4 oder 6.19-rc4 vermag dieses Problem zu lösen. Die Schwachstelle lässt sich auch durch das Einspielen des Patches 0e766b77ba5093583dfe609fae0aa1545c46dbbd/06e219f6a706c367c93051f408ac61417643d2f9 lösen. Dieser kann von git.kernel.org bezogen werden. Als bestmögliche Massnahme wird das Upgrade auf eine neue Version empfohlen.

Unter anderem wird der Fehler auch in den Datenbanken von Tenable (296382) und CERT Bund (WID-SEC-2026-0215) dokumentiert. Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Betroffen

  • Debian Linux
  • Amazon Linux 2
  • Red Hat Enterprise Linux
  • Ubuntu Linux
  • SUSE Linux
  • Oracle Linux
  • IBM QRadar SIEM
  • SUSE openSUSE
  • RESF Rocky Linux
  • NetApp ActiveIQ Unified Manager
  • Open Source Linux Kernel

Produktinfo

Typ

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 6.7
VulDB Meta Temp Score: 6.6

VulDB Base Score: 5.7
VulDB Temp Score: 5.5
VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

NVD Base Score: 7.8
NVD Vector: 🔒

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VektorKomplexitätAuthentisierungVertraulichkeitIntegritätVerfügbarkeit
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Zuverlässigkeit: 🔍

Exploitinginfo

Klasse: Denial of Service
CWE: CWE-911 / CWE-664
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Teilweise
Lokal: Ja
Remote: Teilweise

Verfügbarkeit: 🔒
Status: Nicht definiert

EPSS Score: 🔒
EPSS Percentile: 🔒

Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔒

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Nessus ID: 296382
Nessus Name: Linux Distros Unpatched Vulnerability : CVE-2025-71152

Threat Intelligenceinfo

Interesse: 🔍
Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: Kernel 6.18.4/6.19-rc4
Patch: 0e766b77ba5093583dfe609fae0aa1545c46dbbd/06e219f6a706c367c93051f408ac61417643d2f9

Timelineinfo

13.01.2026 CVE zugewiesen
23.01.2026 +10 Tage Advisory veröffentlicht
23.01.2026 +0 Tage VulDB Eintrag erstellt
17.05.2026 +114 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: kernel.org

Advisory: git.kernel.org
Status: Bestätigt

CVE: CVE-2025-71152 (🔒)
GCVE (CVE): GCVE-0-2025-71152
GCVE (VulDB): GCVE-100-342555
CERT Bund: WID-SEC-2026-0215 - Linux Kernel: Mehrere Schwachstellen

Eintraginfo

Erstellt: 23.01.2026 16:19
Aktualisierung: 17.05.2026 19:37
Anpassungen: 23.01.2026 16:19 (59), 25.01.2026 14:04 (2), 26.01.2026 13:22 (7), 26.02.2026 23:51 (11), 02.03.2026 09:54 (1), 17.05.2026 19:37 (1)
Komplett: 🔍
Cache ID: 216::103

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

Bitte loggen Sie sich ein, um kommentieren zu können.

Do you know our Splunk app?

Download it now for free!