DEBIAN-CVE-2025-71152

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 offindnetdevicebynode(), 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    dsadevtonetdevice() has a putdevice() call which is missing in    dsaportparseof(), but we can actually even verify that an issue    exists. With CONFIGDEBUGKOBJECTRELEASE=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/fslenetc/unbind  we see these lines in the output diff which appear only with the patch applied:  kobject: 'eno2' (ffff002009a3a6b8): kobjectrelease, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobjectrelease, 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, cpudp->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 (devhold()    and devput()).  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 netdevupperdevlink(). But time still passes at DSA switch probe time between the initial offindnetdevicebynode() 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 offindnetdevicebynode() under rtnllock() 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 dsaunregisterswitch() / dsaswitchshutdown()? 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 cpudp->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 dsatreefindfirst_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---