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---
CVE-2025-71152 is a reference counting vulnerability in the Linux kernel's DSA (Distributed Switch Architecture) subsystem affecting network device conduit management. The vulnerability causes improper tracking of network device references, potentially leading to use-after-free conditions when network interfaces are unregistered. This affects systems using DSA-based network switches, particularly in server and networking infrastructure environments.
Immediate Actions:
1. Identify systems running affected Linux kernel versions (6.19-rc1 through 6.19-rc3 and earlier versions with DSA support)
2. Check if DSA network switches are in use via: cat /sys/class/net/*/phy_device or ethtool -i <interface>
3. Implement network monitoring for unexpected interface state changes
Patching Guidance:
1. Apply the latest stable Linux kernel patch that includes the DSA reference counting fix
2. Test patches in non-production environments first, particularly for network-critical systems
3. Schedule maintenance windows for kernel updates on production systems
4. Verify DSA switch functionality post-patch via network interface status checks
Compensating Controls (if immediate patching not possible):
1. Implement redundant network paths to avoid single points of failure
2. Monitor kernel logs for reference counting warnings: grep -i 'kobject_release\|use-after-free' /var/log/kern.log
3. Implement automated interface monitoring and alerting for unexpected state changes
4. Restrict DSA switch driver reloading/unbinding operations
Detection Rules:
1. Monitor for kernel panic messages related to DSA or network device reference counting
2. Alert on repeated network interface state transitions (up/down cycles)
3. Track kernel module load/unload events for DSA drivers
4. Monitor /sys/class/net/ for unexpected device disappearances
الإجراءات الفورية:
1. تحديد الأنظمة التي تعمل بإصدارات نواة لينكس المتأثرة (6.19-rc1 إلى 6.19-rc3 والإصدارات السابقة مع دعم DSA)
2. التحقق من استخدام محولات شبكة DSA عبر: cat /sys/class/net/*/phy_device أو ethtool -i <interface>
3. تنفيذ مراقبة الشبكة لتغييرات حالة الواجهة غير المتوقعة
إرشادات التصحيح:
1. تطبيق أحدث تصحيح نواة لينكس مستقر يتضمن إصلاح عد مراجع DSA
2. اختبار التصحيحات في بيئات غير الإنتاج أولاً، خاصة للأنظمة الحرجة للشبكة
3. جدولة نوافذ الصيانة لتحديثات النواة على أنظمة الإنتاج
4. التحقق من وظائف محول DSA بعد التصحيح عبر فحوصات حالة واجهة الشبكة
الضوابط البديلة (إذا لم يكن التصحيح الفوري ممكناً):
1. تنفيذ مسارات شبكة زائدة لتجنب نقاط الفشل الفردية
2. مراقبة سجلات النواة لتحذيرات عد المراجع: grep -i 'kobject_release\|use-after-free' /var/log/kern.log
3. تنفيذ مراقبة واجهة آلية والتنبيهات لتغييرات الحالة غير المتوقعة
4. تقييد عمليات إعادة تحميل/إلغاء ربط برنامج تشغيل محول DSA
قواعد الكشف:
1. مراقبة رسائل انهيار النواة المتعلقة بـ DSA أو عد مراجع جهاز الشبكة
2. التنبيه على انتقالات حالة واجهة الشبكة المتكررة (دورات التشغيل/الإيقاف)
3. تتبع أحداث تحميل/تفريغ وحدة النواة لبرامج تشغيل DSA
4. مراقبة /sys/class/net/ لاختفاء الأجهزة غير المتوقع