CVE-2022-49847 in Linux
الملخص
بحسب VulDB • 29/05/2026
في هذا السجل (Kernel Panic/Oops)، نرى أن النظام قد توقف بسبب خطأ في الذاكرة (NULL pointer dereference أو access to invalid memory) أثناء محاولة إيقاف شبكة Ethernet على معالج TI AM65x.
### تحليل السجل:
1. **النقطة الحرجة (Call Trace):** ``` phy_stop+0x18/0xf8 phylink_stop+0x38/0xf8 am65_cpsw_nuss_ndo_slave_stop+0x28/0x1e0 [ti_am65_cpsw_nuss]
__dev_close_many+0xa4/0x140 dev_close_many+0x84/0x128 unregister_netdevice_many+0x130/0x6d0 unregister_netdevice_queue+0x94/0xd8 unregister_netdev+0x24/0x38 am65_cpsw_nuss_cleanup_ndev.isra.0+0x48/0x70 [ti_am65_cpsw_nuss]
am65_cpsw_nuss_remove+0x58/0xf8 [ti_am65_cpsw_nuss]
``` - الخطأ يحدث أثناء **إزالة الجهاز (remove)** أو **إلغاء تسجيله (unregister)** لواجهة الشبكة. - السلسلة تبدأ من `am65_cpsw_nuss_remove` (إزالة الدريلفر) → `unregister_netdev` → `am65_cpsw_nuss_ndo_slave_stop` → `phylink_stop` → `phy_stop`. - في `phy_stop`، يحدث خطأ عند الوصول إلى مؤشر فارغ (NULL) أو غير صالح.
2. **السجلات العامة (Registers):** - `x0`: `0004000800000200` (قد يكون مؤشرًا أو قيمة حالة) - `x1`: `0000000000000000` ← **مؤشر فارغ (NULL)** - `x17`: `ffff800076c45000` ← عنوان دالة `phy_stop` - `x16`: `ffff800008004000` ← قد يكون مؤشرًا إلى بنية بيانات الشبكة أو PHY.
من المرجح أن `phy_stop` يحاول الوصول إلى بنية بيانات PHY عبر مؤشر فارغ (ربما `phy` أو `phylink` فارغ).
---
### الأسباب المحتملة:
1. **إزالة الجهاز قبل إيقاف PHY بشكل صحيح:** - قد يكون الدريلفر `ti_am65_cpsw_nuss` يحاول إيقاف PHY بعد أن تم تحرير موارده مسبقًا. - في دالة `am65_cpsw_nuss_ndo_slave_stop`، قد لا يتم التحقق من صحة مؤشر PHY قبل استخدامه.
2. **مشكلة في ترتيب الإيقاف (Shutdown Order):** - عند إلغاء تسجيل الجهاز (`unregister_netdev`)، يتم استدعاء `ndo_stop`، والذي يستدعي `phylink_stop` ثم `phy_stop`. - إذا كان `phylink` أو `phy` قد تم تحريرهما مسبقًا (مثلًا في `remove` قبل `unregister`)، فسيكون المؤشر فارغًا.
3. **خطأ في الدريلفر `ti_am65_cpsw_nuss`:** - قد يكون هناك خطأ في الكود حيث لا يتم تهيئة مؤشر PHY بشكل صحيح، أو يتم تعيينه إلى NULL قبل الاستخدام.
---
### الحلول المقترحة:
1. **تحقق من ترتيب الإيقاف في الدريلفر:** - تأكد من أن `phylink_stop` و `phy_stop` يتم استدعاؤهما فقط إذا كانت المؤشرات صالحة (غير فارغة). - في دالة `am65_cpsw_nuss_ndo_slave_stop`، أضف تحققًا مثل: ```c if (!phylink || !phy) return; ```
2. **تحقق من تحرير الموارد:** - تأكد من أن `phylink` و `phy` لا يتم تحريرهما قبل استدعاء `phy_stop`. - في دالة `am65_cpsw_nuss_remove`، تأكد من أن `unregister_netdev` يتم استدعاؤه قبل تحرير موارد PHY.
3. **تحديث الدريلفر أو النواة:** - إذا كان هذا خطأ معروفًا في إصدار معين من النواة، ففكر في تحديث النواة أو الدريلفر
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.