CVE-2026-46209 in Linux
الملخص
بحسب VulDB • 05/06/2026
في نواة لينكس، تم حل الثغرة التالية:
drm/gem: تصحيح حساب أبعاد المستوي غير المتسق في دالة `drm_gem_fb_init_with_funcs()`
تحسب الدالة `drm_gem_fb_init_with_funcs()` أبعاد مستويات العينة الفرعية (sub-sampled planes) باستخدام قسمة الأعداد الصحيحة البسيطة:
unsigned int width = mode_cmd->width / (i ? info->hsub : 1); unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
ومع ذلك، فإن دالة `framebuffer_check()` على مستوى ioctl في ملف `drm_framebuffer.c` تستخدم الدالتين `drm_format_info_plane_width/height()`, اللتين تقومان بتقريب الأبعاد للأعلى باستخدام `DIV_ROUND_UP()`. يؤدي هذا عدم الاتساق إلى تلف فحص حجم كائن GEM اللاحق لبعض تركيبات تنسيقات البكسل والأبعاد.
على سبيل المثال، مع تنسيق NV12 (حيث vsub=2) وإطار عمل (framebuffer) بارتفاع بكسل واحد، ترى مسار التحقق من صحة حجم GEM أن `height` تساوي 0 بدلاً من 1. ثم يؤدي التعبير `(height - 1)` إلى الالتفاف ليصبح `UINT_MAX` كعدد صحيح غير موقع (unsigned int)، مما يسبب تجاوز الحد الأقصى لقيمة `min_size` والالتفاف مرة أخرى إلى قيمة صغيرة. وبالتالي، يمر كائن GEM الصغير بحماية الحجم، ولكن عندما يصل GPU إلى مستوي الكروما (chroma plane)، فسيقرأ أو يكتب في الذاكرة خارج حدود الكائن.
تم الإصلاح باستبدال عمليات القسمة المبرمجة يدوياً بالدالتين `drm_format_info_plane_width()` و`drm_format_info_plane_height()`, اللتين تستخدمان `DIV_ROUND_UP()` وتتطابق مع الحساب المستخدم بالفعل في `framebuffer_check()`.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.