
الكشف عن ثغرة أمنية من نوع use-after-return المستندة إلى المكدس في Arduino_Core_STM32، مع تفاصيل حول السبب الجذري التقني، والإصدارات المتأثرة، والإصلاح، بالإضافة إلى تحليل الأثر الأمني.
توجد ثغرة استخدام بعد العودة (Use-After-Return) المستندة إلى المكدس في الإصدارات القديمة من Arduino_Core_STM32 قبل الإصدار 1.7.0.
تقع المشكلة في تنفيذ pwm_start()، حيث يتم تخصيص كائن TIM_HandleTypeDef على المكدس ويتم تمرير عنوانه إلى منطق تهيئة HAL. قد يتم الاحتفاظ بهذا المؤشر لاحقًا في سجل عام لمقابض المؤقتات (timer handle registry) ويتم إلغاء الإشارة إليه بشكل غير متزامن بواسطة روتينات خدمة المقاطعة بعد أن يكون إطار المكدس الأصلي قد عاد بالفعل.
تم تخصيص CVE-2026-26399 لهذه الثغرة من قبل MITRE.
Arduino_Core_STM32stm32duino / نظام STMicroelectronics البيئيv0.1.0 حتى v1.6.1v1.7.0في التنفيذ القديم لـ pwm_start()، يتم إنشاء بنية TIM_HandleTypeDef كمتغير محلي على المكدس:
void pwm_start(...) {
TIM_HandleTypeDef timHandle = {};
HAL_TIM_PWM_Init(&timHandle);
...
}
يتم تمرير عنوان هذا الكائن المحلي إلى منطق دعم HAL وقد يتم تخزينه في حالة إدارة المؤقتات العامة، مثل سجل عام لمقابض المؤقتات.
بعد عودة pwm_start()، لم يعد كائن المكدس صالحًا. ومع ذلك، قد تستمر معالجات مقاطعة المؤقت غير المتزامنة اللاحقة في إلغاء الإشارة إلى المؤشر القديم، مما يسبب تلفًا في الذاكرة وسلوكًا غير محدد.
يشمل التأثير الأمني المحتمل:
نظرًا لأن هذه مشكلة على مستوى المكتبة، فإن قابلية الاستغلال الفعلية تعتمد على كيفية دمج المكتبة الضعيفة في البرنامج الثابت (firmware) وكيف يمكن للمدخلات التي يتحكم فيها المهاجم التأثير على إعادة استخدام المكدس وتوقيت المقاطعات.
cores/arduino/stm32/analog.cpwm_start()TIM_HandleTypeDeftimer_handles)يبدو أن المشكلة قد حُلّت بشكل غير مباشر في الإصدار 1.7.0 أثناء إعادة هيكلة استبدلت مسار المعالجة المستند إلى المكدس السابق بتصميم مختلف لإدارة المؤقتات. لا يبدو أنه تم إصدار استشارة أمنية مخصصة للثغرة القديمة.
تم تحديد هذه المشكلة أثناء بحث أمني للبرامج الثابتة تضمن اختبار التشويش (fuzzing) وتحليل السبب الجذري للبرامج الثابتة القديمة القائمة على STM32 والمبنية على Arduino_Core_STM32.
تم التواصل مع PSIRT الخاص بالبائع. أشار الرد إلى أن الإصدارات الحالية غير متأثرة لأن المشكلة قد حُلّت بالفعل في الإصدار 1.7.0، ولكن لا يبدو أن البائع قد طلب CVE مخصصًا في ذلك الوقت.
تم اكتشافها بواسطة Jin Chang.
CVE-2026-26399