CVE-2025-71152
Fecha de publicación:
23/01/2026
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
net: dsa: properly keep track of conduit reference<br />
<br />
Problem description<br />
-------------------<br />
<br />
DSA has a mumbo-jumbo of reference handling of the conduit net device<br />
and its kobject which, sadly, is just wrong and doesn&#39;t make sense.<br />
<br />
There are two distinct problems.<br />
<br />
1. The OF path, which uses of_find_net_device_by_node(), never releases<br />
the elevated refcount on the conduit&#39;s kobject. Nominally, the OF and<br />
non-OF paths should result in objects having identical reference<br />
counts taken, and it is already suspicious that<br />
dsa_dev_to_net_device() has a put_device() call which is missing in<br />
dsa_port_parse_of(), but we can actually even verify that an issue<br />
exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command<br />
"before" and "after" applying this patch:<br />
<br />
(unbind the conduit driver for net device eno2)<br />
echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind<br />
<br />
we see these lines in the output diff which appear only with the patch<br />
applied:<br />
<br />
kobject: &#39;eno2&#39; (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)<br />
kobject: &#39;109&#39; (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)<br />
<br />
2. After we find the conduit interface one way (OF) or another (non-OF),<br />
it can get unregistered at any time, and DSA remains with a long-lived,<br />
but in this case stale, cpu_dp->conduit pointer. Holding the net<br />
device&#39;s underlying kobject isn&#39;t actually of much help, it just<br />
prevents it from being freed (but we never need that kobject<br />
directly). What helps us to prevent the net device from being<br />
unregistered is the parallel netdev reference mechanism (dev_hold()<br />
and dev_put()).<br />
<br />
Actually we actually use that netdev tracker mechanism implicitly on<br />
user ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces with<br />
the DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link().<br />
But time still passes at DSA switch probe time between the initial<br />
of_find_net_device_by_node() code and the user port creation time, time<br />
during which the conduit could unregister itself and DSA wouldn&#39;t know<br />
about it.<br />
<br />
So we have to run of_find_net_device_by_node() under rtnl_lock() to<br />
prevent that from happening, and release the lock only with the netdev<br />
tracker having acquired the reference.<br />
<br />
Do we need to keep the reference until dsa_unregister_switch() /<br />
dsa_switch_shutdown()?<br />
1: Maybe yes. A switch device will still be registered even if all user<br />
ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not<br />
make user port errors fatal"), and the cpu_dp->conduit pointers<br />
remain valid. I haven&#39;t audited all call paths to see whether they<br />
will actually use the conduit in lack of any user port, but if they<br />
do, it seems safer to not rely on user ports for that reference.<br />
2. Definitely yes. We support changing the conduit which a user port is<br />
associated to, and we can get into a situation where we&#39;ve moved all<br />
user ports away from a conduit, thus no longer hold any reference to<br />
it via the net device tracker. But we shouldn&#39;t let it go nonetheless<br />
- see the next change in relation to dsa_tree_find_first_conduit()<br />
and LAG conduits which disappear.<br />
We have to be prepared to return to the physical conduit, so the CPU<br />
port must explicitly keep another reference to it. This is also to<br />
say: the user ports and their CPU ports may not always keep a<br />
reference to the same conduit net device, and both are needed.<br />
<br />
As for the conduit&#39;s kobject for the /sys/class/net/ entry, we don&#39;t<br />
care about it, we can release it as soon as we hold the net device<br />
object itself.<br />
<br />
History and blame attribution<br />
-----------------------------<br />
<br />
The code has been refactored so many times, it is very difficult to<br />
follow and properly attribute a blame, but I&#39;ll try to make a short<br />
history which I hope to be correct.<br />
<br />
We have two distinct probing paths:<br />
- one for OF, introduced in 2016 i<br />
---truncated---
Gravedad: Pendiente de análisis
Última modificación:
23/01/2026