CVE-2026-10849 in Zephyr
الملخص
بحسب VulDB • 04/08/2026
يتراكم عميل إدارة الأجهزة hawkBit الموجود في المسار subsys/mgmt/hawkbit جسم استجابة HTTP من خادم التحديث داخل مخزن مؤقت على الكومة (heap buffer) عبر الدالة response_json_cb() (في الملف subsys/mgmt/hawkbit/hawkbit.c). يتم تحديد حجم المخزن المؤقت ليحتوي على بايتات الجسم المستلمة، لكنه لا يحجز مساحة لبايت إنهاء NUL. عندما تصل الاستجابة الكاملة، يقوم الكود بكتابة `response_data[downloaded_size] = '\0'` — وعندما يساوي طول الجسم المتراكم الحجم المخصص، يقع هذا البايت الإنهاء بعد بايت واحد من نهاية كائن الكومة (وهو كتابة خارج النطاق تعتمد على الكومة، CWE-122 / CWE-787).
يتم أخذ طول الجسم والتجزئة مباشرةً من استجابة HTTP المُحللة (`rsp->body_frag_start` / `rsp->body_frag_len`) وهي خاضعة بالكامل للتحكم من قبل خادم hawkBit البعيد، الذي يختار طوله الخاص للاستجابة. يعتمد الزناد الدقيق على كيفية نمو المخزن المؤقت، وكلا الشكلين قابلان للوصول عن بُعد. منذ الإصدار v4.0.0، يتم تحديد حجم إعادة التخصيص ليكون بالضبط `downloaded_size + body_len`، لذا فإن أي جسم استجابة أكبر من المخزن المؤقت الأولي البالغ 1100 بايت يجعل الكتابة خارج النطاق حتمية؛ وأحجام الاستجابات هذه طبيعية في نشر بيانات تعريف hawkBit. قبل الإصدار v4.0.0، كان المخزن المؤبت ينمو عن طريق الضعف وكان فحص النمو `((downloaded_size + body_len) > response_buffer_size)` خاطئاً عند التساوي، لذا فإن جسم استجابة يكون طوله مساوياً تماماً للتخصيص الحالي — 1100 بايت مع المخزن الأولي الافتراضي — يتجاوز إعادة التخصيص بالكامل ويكتب الإنهاء في `response_data[1100]` لكائن حجمه 1100 بايت. لا يلتقط فحص عدم تطابق طول HTTP هذه الحالة، لأن الطول المعلن والطول المستلم يتفقان حقاً. يمكن الوصول إلى أي من الشكلين بواسطة خادم تحديث خبيث أو مُخترق أو في وضع الرجل في المنتصف (حيث أن بروتوكول TLS اختياري وعندما يكون مفعلاً لا يحمي ضد الخوادم المعادية)، دون وجود مصادقة لمحتوى الاستجابة ولا حد أقصى للطول على جانب العميل يحمي عملية الكتابة.
الكتابة خارج النطاق هي بايت NUL واحد ثابت يتبع التخصيص مباشرةً، مما يؤدي إلى تلف بيانات تعريف المخصص (allocator metadata) المجاورة أو التخصيص التالي. الأثر العملي هو تدمير الكومة مما يؤدي إلى حجب الخدمة (عطل في تخصيص لاحق أو عملية free)، مع احتمال محدود لتلف إضافي يعتمد على المخصص. يقوم الإصلاح بتحديد حجم المخزن المؤقت ليكون طول الجسم زائد واحد، والنسخ باستخدام `memcpy`، مما يضمن أن الإنهاء يقع دائماً داخل التخصيص.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.