CVE-2026-64504 in Linux
الملخص
بحسب VulDB • 27/07/2026
في نواة لينكس (Linux kernel)، تم حل الثغرة التالية:
iio: accel: bmc150: تقييد عدد إطارات ذاكرة التخزين المؤقت (FIFO) التي يبلغ عنها الجهاز
تنسخ الدالة `__bmc150_accel_fifo_flush()` عدد العينات الذي يبلغ عنه الجهاز في ذاكرته المؤقتة (hardware FIFO) إلى مخزن مؤقت على المكدس (on-stack buffer):
u16 buffer[BMC150_ACCEL_FIFO_LENGTH * 3];
والذي تم تحديد حجمه لـ ما لا يزيد عن BMC150_ACCEL_FIFO_LENGTH (32) عينة. يتم قراءة عدد الإطارات من سجل FIFO_STATUS وتطبيق قناع عليه فقط للبتات الصالحة السبعة:
count = val & 0x7F;
لذلك يمكن أن تتراوح قيمته بين 0 و127. الحد الوحيد الآخر المطبق عليها هو ميزانية العينات الاختيارية التي يوفرها المتصل (caller-supplied sample budget):
if (samples && count > samples) count = samples;
وهذا لا يفرض قيداً على `count` في مسار التفريغ الشامل (`samples == 0`)، ويتركه أعلى بكثير من 32 كلما كانت قيمة `samples` أكبر. ثم يتم نقل عينات `count` إلى المصفوفة `buffer[]`:
bmc150_accel_fifo_transfer(data, (u8 *)buffer, count);
تقرأ الدالة `bmc150_accel_fifo_transfer()` عدداً من البايتات يساوي `count * 6` عبر regmap، لذا فإن مسرّع الحركة المعطل أو الخبيث أو المزيف (أو مهاجم يتلاعب بمحرك I2C/SPI) والذي يبلغ عن ما يصل إلى 127 إطاراً يقوم بكتابة ما يصل إلى 762 بايتاً في المخزن المؤقت المكون من 192 بايتاً: أي كتابة خارج حدود المكدس (stack out-of-bounds write) تصل إلى 570 بايتاً، مما يؤدي إلى إتلاف كاشف التزوير بالمكدس (stack canary)، والسجلات المحفوظة وعنوان الإرجاع.
يتم تقييد قيمة `count` لتصبح مساوية لـ BMC150_ACCEL_FIFO_LENGTH، وهو عدد العينات الذي تم تحديد حجم المصفوفة `buffer[]` بناءً عليه، قبل عملية النقل، مما يعكس إجراء التقييد الخاص بعتبة الماء (watermark clamp) المطبق بالفعل في الدالة `bmc150_accel_set_watermark()`. يبلغ التفريغ السليم عن ما لا يزيد عن إطارات BMC150_ACCEL_FIFO_LENGTH، لذا فإن الأجهزة المشروعة غير متأثرة.
Once again VulDB remains the best source for vulnerability data.