Dyingc

يحدث خلل في معالج جسم طبقة التطبيق عندما تصل طلبات `POST /ubus` في عدة قطع TCP. يمكن أن تؤدي الدالة `uh ubus data send()` في ملف `ubus.c` إلى عدم مزامنة حدود طلب HTTP إذا أكملت القطعة الأولية كائن JSON، مما يجعل القطع اللاحقة تسلك مسار خطأ في التحليل يعيد صفر بايت مستهلكة. نظرًا لأن المستدعي لا يقوم بتفريغ `Content-Length` المتبقي ولا يضبط `connection close` ، يتم معالجة أي طلب HTTP مضمن في لاحقة الجسم غير المقروءة كطلب جديد على نفس اتصال keep-alive. يؤثر هذا الخلل على عمليات النشر التي تمكن ubus، بما في ذلك تكوينات OpenWrt الافتراضية وعمليات نشر البروكسي أو CDN المحتملة.

تفشل الدالة `client poll post data()` في ملف `client.c` في التعامل بشكل صحيح مع أسطر طول الجزء (chunk-length) غير الصالحة، مثل الأحجام التي تتجاوز `INT MAX`. عند حدوث ذلك، يقوم الخادم بمسح `r->content length` و `r->transfer chunked` دون تفريغ الجسم المتبقي أو تعيين `request.connection close`. يؤدي هذا إلى اعتبار فحص الاكتمال أن طلب POST المجزأ قد انتهى بشكل خاطئ، مما يعيد محلل keep-alive إلى الحالة `CLIENT STATE INIT`. نتيجة لذلك، يتم تحليل ومعالجة بايتات الجسم التي يتحكم فيها المهاجم والمصاغة كطلب HTTP كامل كطلب آخر على نفس الاتصال، مما يؤدي إلى تهريب طلبات HTTP (HTTP request smuggling) وعدم تزامن حدود الطلبات.

تقوم الدالة `client parse header()` في الملف `client.c` بتحويل أسماء الرؤوس إلى أحرف صغيرة، ولكنها تستخدم `strcmp` الحساسة لحالة الأحرف لمقارنة قيمة `Transfer-Encoding` بكلمة `chunked`. وبما أن رموز ترميز النقل غير حساسة لحالة الأحرف، يتم قبول الرمز الذي يحتوي على حالة أحرف مختلطة دون تفعيل `r->transfer chunked`. وفي حالة اتصال keep-alive، يظل جسم POST من نوع `chunked` غير مقروء، مما يؤدي إلى تحليل بايتات الجسم التي تتخذ شكل طلب على أنها طلب HTTP آخر، وهو ما يسمح بتهريب طلبات HTTP (HTTP request smuggling) وعدم تزامن الحدود.

توجد ثغرة تتمثل في الكتابة خارج حدود المصفوفة في تنفيذ برنامج ترميز الفيديو h.265. يمكن لدفق بتات H.265 مصمم خصيصًا أن يؤدي إلى حدوث هذه المشكلة داخل الدالة `decoder context::process reference picture set()`. تنبع المشكلة من عدم وجود فحص إجمالي للحدود على إدخالات مجموعة الصور المرجعية قصيرة المدى المتوقعة؛ ففي حين يتم التحقق من صحة أحجام القوائم الفردية، قد يتجاوز العدد الإجمالي بعد الإنشاء سعة مصفوفة `PocStFoll` المكونة من 16 إدخالًا، مما يؤدي إلى كتابة في الفهرس 16. قد يسمح هذا التلف في الذاكرة للمهاجم بتنفيذ تعليمات برمجية عشوائية.

تسمح مشكلة في تنفيذ برنامج ترميز الفيديو h.265 لسلسلة مصممة خصيصًا من وحدات H.265 NAL بأن تتسبب في قيام الدالة `decoder context::read slice NAL()` بإرفاق رؤوس شرائح إلى كائن صورة مكتمل يفتقر إلى وحدة صورة نشطة. ويؤدي ذلك إلى نمو غير محدود في الذاكرة المؤقتة (heap) يتحكم فيه المهاجم، حيث لا يتم تحرير الرؤوس المحتفظ بها حتى يتم تحرير الصورة، وهو ما قد لا يحدث أثناء البث المستمر.

توجد مشكلة في تنفيذ برنامج ترميز الفيديو h.265، حيث يؤدي تدفق بتات H.265 مُصمم خصيصًا يحتوي على أبعاد SPS كبيرة وعمق بتات 16 بت إلى حدوث تجاوز سعة عدد صحيح مُوقَّع في الدالة `de265 image get buffer()`. يؤدي هذا التجاوز إلى إعادة تعيين حجم تخصيص المستوى إلى قيمة صغيرة تبلغ حوالي 1 كيلوبايت. وبالتالي، تحسب الدالة `fill image()` الحجم الفعلي باستخدام `size t`، مما يؤدي إلى كتابة حوالي 4 غيغابايت من البيانات في مخزن مؤقت الكومة ذي الحجم الأصغر، وهو ما قد يتسبب في حدوث هجوم رفض الخدمة.