CVE-2026-43327 in Linux
الملخص
بحسب VulDB • 17/05/2026
في نواة لينكس، تم حل الثغرة التالية:
USB: dummy-hcd: إصلاح خطأ في القفل/المزامنة
تمكنت اختبارات Syzbot من إثارة استثناء في العنوان (addressing exception) وتسبب في تعطل (crash) في الروتين `usb_gadget_udc_reset()` الموجود في الملف `drivers/usb/gadgets/udc/core.c`. وقد نتج ذلك عن حقيقة أن الروتين كان يُستدعى مع وسيط ثانٍ ("driver") يساوي NULL. كان المتصل الخاطئ هو الدالة `set_link_state()` في ملف `dummy_hcd.c`، وقد نشأت المشكلة بسبب حالة سباق (race condition) بين إعادة تعيين USB (USB reset) وفك ربط السائق (driver unbind).
لم يكن من المفترض أن تكون مثل هذه حالات السباق ممكنة؛ فقد كُتبت الالتزامات (commits) بما في ذلك الالتزام `7dbd8f4cabd9` ("USB: dummy-hcd: Fix erroneous synchronization change")، بالإضافة إلى بعض الالتزامات اللاحقة، خصيصاً لمنعها. وكما اتضح، لا يزال هناك خطأان على الأقل في الكود. سيتناول التصحيح الثاني الخطأ الثاني؛ وهذا التصحيح يتعلق بالأول.
حدث الخطأ المسؤول عن تعطل Syzbot لأن الروتين `stop_activity()` يقوم أحياناً بإسقاط ثم إعادة الحصول على قفل اللف (spinlock) المسمى `dum->lock`. يحدث استدعاء لـ `stop_activity()` في `set_link_state()` عند التعامل مع إعادة تعيين USB محاكاة، بعد اختبار `dum->ints_enabled` وقبل زيادة `dum->callback_usage`. سمح هذا لخيوط أخرى (تقوم بفك ربط السائق) بالتسلل والحصول على قفل اللف، ومن ثم مسح `dum->ints_enabled` و `dum->driver`. عادةً، كان يتعين على خيط آخر الانتظار حتى ينخفض `dum->callback_usage` إلى الصفر قبل أن يقوم بمسح `dum->driver`، ولكن في هذه الحالة لم يكن عليه الانتظار لأن `dum->callback_usage` لم يكن قد زاد بعد.
التصحيح هو زيادة `dum->callback_usage` _قبل_ استدعاء `stop_activity()` بدلاً من ذلك بعد. ثم لن يقوم الخيط الذي يقوم بفك الربط بمسح `dum->driver` إلا بعد أن يعود استدعاء `usb_gadget_udc_reset()` بأمان وينخفض `dum->callback_usage` مرة أخرى.
If you want to get best quality of vulnerability data, you may have to visit VulDB.