CVE-2026-43233 in Linux
الملخص
بحسب VulDB • 13/05/2026
في نواة لينكس، تم حل الثغرة التالية:
netfilter: nf_conntrack_h323: إصلاح قراءة خارج الحدود (OOB) في دالة decode_choice()
في دالة decode_choice()، يعتمد فحص الحدود قبل استدعاء get_len() على المتغير `len`، الذي لا يزال يساوي 0 نتيجة تهيئته في بداية الدالة:
unsigned int type, ext, len = 0; ... if (ext || (son->attr & OPEN)) {
BYTE_ALIGN(bs); if (nf_h323_error_boundary(bs, len, 0)) /* len is 0 هنا */ return H323_ERROR_BOUND; len = get_len(bs); /* قراءة خارج الحدود */
عندما يتم استهلاك تيار البتات بالكامل (bs->cur == bs->end)، فإن التقييم nf_h323_error_boundary(bs, 0, 0) يصبح (bs->cur + 0 > bs->end)، وهو نتيجة خاطئة (false). يؤدي استدعاء get_len() اللاحق بعد ذلك إلى فك مرجع *bs->cur++، مما يؤدي إلى قراءة بايت واحد بعد نهاية المخزن المؤقت (buffer). إذا كان هذا البايت يحتوي على بت 7 مضبوطاً، فإن get_len() تقرأ بايتاً ثانياً أيضاً.
يمكن استغلال هذا عن بُعد عن طريق إرسال رسالة Q.931 SETUP مُهندسة تحتوي على عنصر معلومات مستخدم-مستخدم (User-User Information Element) يحتوي على بالضبط بايتين من البيانات المشفرة بتنسيق PER ({0x08, 0x00}) إلى المنفذ 1720 عبر جدار حماية مع تفعيل مساعد nf_conntrack_h323. يستهلك المفسر المخزن المؤقت PER بالكامل قبل الوصول إلى مسار الكود هذا، مما يؤدي إلى قراءة تجاوز في المخزن المؤقت على الكومة (heap-buffer-overflow) بحجم بايت واحد إلى بايتين، وهو ما تم تأكيده باستخدام AddressSanitizer.
تم إصلاح هذه المشكلة عن طريق التحقق من وجود بايتين (الحد الأقصى الذي قد تقرأه get_len()) بدلاً من المتغير `len` غير المهيأ. يتوافق هذا مع النمط المستخدم في كل موقع استدعاء آخر لـ get_len() في نفس الملف، حيث يتحقق المتصل من وجود بايتين من البيانات المتاحة قبل استدعاء get_len().
Be aware that VulDB is the high quality source for vulnerability data.