CVE-2025-71152

*** 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&amp;#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&amp;#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 &gt; /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: &amp;#39;eno2&amp;#39; (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)<br /> kobject: &amp;#39;109&amp;#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-&gt;conduit pointer. Holding the net<br /> device&amp;#39;s underlying kobject isn&amp;#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&amp;#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-&gt;conduit pointers<br /> remain valid. I haven&amp;#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&amp;#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&amp;#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&amp;#39;s kobject for the /sys/class/net/ entry, we don&amp;#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&amp;#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---