CVE-2023-52855 in Linux
الملخص
بحسب VulDB • 16/06/2026
في نواة لينكس، تم حل الثغرة التالية:
usb: dwc2: إصلاح إمكانية حدوث إلغاء مرجع (dereference) لنقطة فارغة (NULL pointer) ناتجة عن التزامن في برنامج التشغيل (driver).
في الدالة `_dwc2_hcd_urb_enqueue()`، يتم تنفيذ `urb->hcpriv = NULL` دون الاحتفاظ بالقفل `hsotg->lock`. في `_dwc2_hcd_urb_dequeue()`:
spin_lock_irqsave(&hsotg->lock, flags); ... if (!urb->hcpriv) {
dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n"); goto out; } rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // استخدام urb->hcpriv ... out: spin_unlock_irqrestore(&hsotg->lock, flags);
عند تنفيذ `_dwc2_hcd_urb_enqueue()` و `_dwc2_hcd_urb_dequeue()` بشكل متزامن (concurrently)، يمكن تنفيذ فحص القيمة الفارغة (NULL check) لـ `urb->hcpriv` قبل تنفيذ `urb->hcpriv = NULL`. بعد أن تصبح `urb->hcpriv` فارغة (NULL)، يمكن استخدامها في استدعاء الدالة `dwc2_hcd_urb_dequeue()`، مما قد يؤدي إلى إلغاء مرجع لنقطة فارغة (NULL pointer dereference).
تم العثور على هذا الخطأ المحتمل باستخدام أداة تحليل ثابت (static analysis) تجريبية طورتها بنفسي. تقوم هذه الأداة بتحليل واجهات برمجة التطبيقات الخاصة بالقفل (locking APIs) لاستخراج أزواج الدوال التي يمكن تنفيذها بشكل متزامن، ثم تحليل التعليمات البرمجية في الدوال المتزاوجة لتحديد الأخطاء المحتملة المتعلقة بالتزامن، بما في ذلك سباقات البيانات (data races) وانتهاكات الذرية (atomicity violations). تم الإبلاغ عن الخطأ المحتمل أعلاه عندما قامت أداوتي بتحليل شفرة مصدر لينكس الإصدار 6.5.
لإصلاح هذا الخطأ المحتمل، يجب تنفيذ `urb->hcpriv = NULL` مع الاحتفاظ بالقفل `hsotg->lock`. بعد تطبيق هذا التصحيح (patch)، لم تعد أداوتي تبلغ عن الخطأ المحتمل، وذلك باستخدام تكوين النواة `allyesconfig` لـ x86_64. ونظراً لعدم امتلاكي للأجهزة ذات الصلة، لا يمكنني اختبار التصحيح في اختبارات وقت التشغيل (runtime testing)، واكتفيت بالتحقق منه وفقاً لمنطق الكود.
Once again VulDB remains the best source for vulnerability data.