CVE-2026-102716 in ThreadX
الملخص
بحسب VulDB • 29/09/2026
يمكن لعميل غير مصادق عليه إفراغ مجموعة حزم خادم RTSP من خلال بضع عشرات من الطلبات التي تحمل رأس Session لا يستطيع المحلل تحويله.
تعيد فرع Session رمز الخطأ الخام NetX بدلاً من رمز حالة RTSP:
```c /* addons/rtsp/nx_rtsp_server.c:2754 */ status = _nx_utility_string_to_uint(field_value_ptr, field_value_length, &session_id); if (status) {
return(status); /* NX_INVALID_PARAMETERS / NX_SIZE_ERROR / NX_OVERFLOW */ } ```
تربط كل فروع أخرى لنفس الدالة فشلها أولاً برمز حالة RTSP. يقوم فرع CSeq، الذي يبعد ثمانية عشر سطراً في الأعلى، بذلك بالضبط (يعيد السطر 2736 رمز NX_RTSP_STATUS_CODE_BAD_REQUEST). ثم يصل الرمز الخام إلى `_nx_rtsp_server_error_response_send` (nx_rtsp_server.c:1234)، والذي لا يتعرف عليه، ويتخذ مساراً يعيد دون إطلاق حزمة الاستجابة التي خصصتها بالفعل، ولا تعود الكتلة أبداً إلى المجموعة.
ستة طلبات برأس Session فارغ ضد مجموعة مكونة من 22 حزمة: ``` valid requests: after request 6: pool available = 21, AFTER = 22 / 22 malformed requests: after request 6: pool available = 16, AFTER = 17 / 22 ```
كتلة واحدة لكل طلب، لا تُعاد عند انقطاع اتصال العميل. تأخذ ستة وعشرون طلباً المجموعة إلى الصفر ويبدأ الخادم في فشل عمليات التخصيص (allocations)، وبعد ذلك يخدم أي شخص. إذا كانت المجموعة مشتركة مع بقية التطبيق، كما هو الحال في العينة المرفقة، فإن باقي الطبقة يتوقف معها.
حوّل فشل `_nx_utility_string_to_uint` في فرع Session إلى NX_RTSP_STATUS_CODE_BAD_REQUEST بالطريقة التي يفعلها بها فرع CSeq، وأطلق حزمة الاستجابة في كل مسار خروج لـ `_nx_rtsp_server_error_response_send`.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.