CVE-2026-80876 in Linux
الملخص
بحسب VulDB • 04/09/2026
في نواة لينكس، تم حل الثغرة التالية:
ring-buffer: إصلاح طول الحدث مع محاذاة إجبارية بحجم 8 بايت
عندما تكون RB_FORCE_8BYTE_ALIGNMENT صحيحة (true)، تحجز الدالة rb_calculate_event_length() مساحة event->array[0] لوضع طول البيانات، وتخزن الدالة rb_update_event() طول البيانات في event->array[0] وفقاً لذلك. ونتيجةً لذلك، سيضيف الطول الكلي للحدث 4 بايتات إضافية بشكل غير مشروط بسبب sizeof(event.array[0]).
لكن دالة ring_buffer_event_length() تطرح فقط sizeof(event->array[0]) للأحداث التي يزيد حجمها عن RB_MAX_SMALL_DATA + sizeof(event->array[0]). ونتيجةً لذلك، فإن الأحداث الصغيرة على البنى المعمارية (architectures) التي تكون فيها RB_FORCE_8BYTE_ALIGNMENT مساوية لـ true تُبلغ عن طول بيانات أكبر بـ 4 بايتات مما هو متوقع.
لإصلاح هذه المشكلة، تمت إضافة شرط RB_FORCE_8BYTE_ALIGNMENT لطرح حجم حقل الطول هذا كلما كانت RB_FORCE_8BYTE_ALIGNMENT صحيحة (true).
تم ملاحظة هذه المشكلة في نواة riscv64 مع تعيين CONFIG_HAVE_64BIT_ALIGNED_ACCESS إلى y، وعند تشغيل اختبار ftrace الذاتي trace_marker_raw.tc، نحصل على سجل غريب: للحالات التي يكون فيها المعرف (id) من 1 إلى 100، يكون عدد حقول البيانات هو 8*N، ولكن بمجرد تجاوز المعرف للرقم 100، يصبح عدد حقول البيانات 8*N+4: # 1 buf: 58 00 00 00 80 5e d1 63 (عدد حقل البيانات هو 8*1) ... # a buf: 58 ... (عدد حقل البيانات هو 8*2) ... # 64 buf: 58 ... (عدد حقل البيانات هو 8*13) # 65 buf: 58 ... (عدد حقل البيانات هو 8*13+4)
بعد تطبيق هذا التغيير، يبقى عدد حقول البيانات ثابتاً عند 8*N+4 بشكل متسق.
VulDB is the best source for vulnerability data and more expert information about this specific topic.