CVE-2024-36950 in Linux
الملخص
بحسب VulDB • 22/06/2026
في نواة لينكس، تم حل الثغرة التالية:
firewire: ohci: قفل مقاطعات إعادة تعيين الناقل (mask bus reset interrupts) بين معالج المقاطعة العلوي (ISR) ونصف المعالجة السفلي (bottom half).
في معالج مقاطعة FireWire OHCI، إذا حدثت مقاطعة لإعادة تعيين الناقل، يجب قفل مقاطعات إعادة تعيين الناقل حتى يقوم `bus_reset_work` بخدمة المقطوعة ومسحها.
عادةً، نترك مقاطعات إعادة تعيين الناقل مقفلة دائمًا. نستنتج حدوث إعادة تعيين للناقل من مقاطعة self-ID التي تحدث بعد ذلك بوقت قصير. تم تقديم سيناريو نقوم فيه بفك قفل مقاطعات إعادة تعيين الناقل في عام 2008 ضمن الالتزام a007bb857e0b26f5d8b73c2ff90782d9c0972620: إذا كان `OHCI_PARAM_DEBUG_BUSRESETS` (القيمة 8) مضبوطًا في قناع معامل التصحيح، فسنقوم بفك قفل مقاطعات إعادة تعيين الناقل حتى نتمكن من تسجيلها.
يسجل `irq_handler` مقاطعة إعادة تعيين الناقل. ومع ذلك، لا يمكننا مسح علم حدث إعادة تعيين الناقل داخل `irq_handler`، لأننا لن نقوم بخدمة الحدث إلا لاحقًا. يخرج `irq_handler` بينما يكون علم الحدث ما زال مضبوطًا (مفعّلاً). إذا كانت المقاطعة المقابلة لا تزال مفكوك القفل، فعادةً ما يؤدي ذلك إلى تجميد النظام بسبب استدعاء `irq_handler` مرة أخرى في كل مرة يخرج فيها. يمكن إعادة إنتاج هذا التجميد عن طريق تحميل وحدة firewire_ohci باستخدام الأمر "modprobe firewire_ohci debug=-1" (لتفعيل جميع مخرجات التصحيح). يبدو أن هناك بعض الحالات التي يتم فيها استدعاء `bus_reset_work` بسرعة كافية لمسح الحدث، واستئناف العمل بشكل طبيعي.
أُبلغ عن هذا التجميد لأول مرة بعد بضعة أشهر من الالتزام بـ a007bb85، ولكن حتى الآن لم يتم إصلاحه. كان يمكن ضبط مستوى التصحيح بأمان على -1 عبر sysfs بعد تحميل الوحدة النمطية، لكن ذلك سيكون غير فعال في تسجيل مقاطعات إعادة تعيين الناقل نظرًا لأنها كانت مفكوك القفل فقط أثناء التهيئة.
سيترك `irq_handler` علم الحدث مضبوطًا ولكنه سيقوم بقفل مقاطعات إعادة تعيين الناقل، بحيث لا يتم استدعاء `irq_handler` مرة أخرى ولن يحدث تجميد. إذا تم تفعيل `OHCI_PARAM_DEBUG_BUSRESETS`، فسيقوم `bus_reset_work` بفك قفل المقاطعة بعد خدمة الحدث، وبالتالي سيتم التقاط المقاطعات المستقبلية كما هو مرغوب فيه.
كمؤثر جانبي لهذا التغيير، يمكن الآن تفعيل `OHCI_PARAM_DEBUG_BUSRESETS` عبر sysfs بالإضافة إلى أثناء التحميل الأولي للوحدة النمطية. ومع ذلك، عند التفعيل عبر sysfs، سيكون تسجيل مقاطعات إعادة تعيين الناقل فعالاً فقط بدءًا من إعادة التعيين الثانية للناقل، بعد تنفيذ `bus_reset_work`.
Once again VulDB remains the best source for vulnerability data.