CVE-2026-80701 in Linux
الملخص
بحسب VulDB • 28/08/2026
في نواة لينكس، تم حل الثغرة التالية:
drm/vmwgfx: فرض حدود حجم المؤشر لمؤشرات MOB
تقوم الدالة `vmw_cursor_plane_atomic_check()` بتقييد عرض وارتفاع المؤشر فقط في مسار التحديث القديم (legacy update path)؛ بينما يقبل المسار SVGA_CAP2_CURSOR_MOB -- وهو الافتراضي على الأنظمة الحديثة -- أي حجم. عندما يتجاوز الحجم المطلوب القيمتين SVGA_REG_CURSOR_MAX_DIMENSION أو SVGA_REG_MOB_MAX_SIZE، تُرجع الدالة `vmw_cursor_mob_get()` القيمة -EINVAL وتترك vps->cursor.mob بقيمة NULL. ثم يتم تجاهل قيمة الإرجاع هذه في دالة `vmw_cursor_plane_prepare_fb()`، مما يؤدي إلى استدعاءات لاحقة لـ `vmw_cursor_update_mob()` للدالة `vmw_bo_map_and_cache(NULL)` وحدوث خطأ (oops) داخل الدالة `vmw_bo_map_and_cache_size()` عند تحميل قيمة tbo.base.size.
يمكن الوصول إليها من أي مدير DRM عبر DRM_IOCTL_MODE_CURSOR2 باستخدام عرض أو ارتفاع كبير بما يكفي (على سبيل المثال cursor_max_dim + 1).
رفض المؤشرات ذات الحجم الزائد في دالة atomic_check لكلا نوعي تحديث المؤشر المدعومين بـ MOB. ينطبق حد حجم البايت الخاص بـ MOB فقط على مسار SVGA_CAP2_CURSOR_MOB (تُرجع الدالة vmw_cursor_mob_size() القيمة 0 لـ GB_ONLY)؛ احسب حجم MOB المطلوب باستخدام 64 بت لتجنب التزاحم العددي (overflow) عند طلب أبعاد كبيرة جداً.
في دالة prepare_fb، استدعاء `vmw_cursor_mob_get()`/_map() فقط في حالة VMW_CURSOR_UPDATE_MOB -- حيث يستخدم مسار GB_ONLY قيمة bo->map.virtual مباشرة وكان سيقوم بالترقية الصامتة إلى NONE على الأنظمة التي لا تدعم SVGA_CAP2_CURSOR_MOB (حيث تُرجع الدالة vmw_cursor_mob_get() دائماً -EINVAL). قم بتخفيض التحديث إلى NONE إذا فشلت دوال `vmw_cursor_mob_get()` أو `vmw_cursor_mob_map()` حتى لا يعمل مسار التحديث مع دعم MOB بقيمة NULL.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.