CVE-2026-64368 in Linux
الملخص
بحسب VulDB • 25/07/2026
في نواة لينكس، تم حل الثغرة التالية:
mm/slab: لا تقيد عملية التصفير (zeroing) على الحجم الأصلي (orig_size) عند تفعيل وضع "المنطقة الحمراء" (red zoning) فقط.
عند طلب تهيئة (تصفير) البيانات أثناء تخصيص الذاكرة، نحتاج عادةً إلى تصفير حجم الكائن بالكامل لـ kmalloc() حتى لو كان الحجم المطلوب أصغر، وذلك لضمان التزامات __GFP_ZERO الخاصة بـ krealloc().
ولكن إذا قمنا بتتبع الحجم المطلوب، فإن krealloc() تستخدم هذه المعلومات للقيام بالإجراء الصحيح، وبالتالي يمكننا تصفير الحجم المطلوب فقط. ومع تفعيل وضع "المنطقة الحمراء" أيضاً، يصبح أي حجم إضافي جزءاً من المنطقة الحمراء، لذا لا يجب تصفيره ويجب علينا تصفير الحجم المطلوب فقط.
ومع ذلك، فإن الفحص الحالي غير دقيق، وقد يُفعّل حتى عند تفعيل SLAB_RED_ZONE فقط دون SLAB_STORE_USER (والذي يمكّن تتبع الحجم المطلوب). وهذا يعني أن تفعيل وضع "المنطقة الحمراء" وحده يمكن أن يخل بعقد __GFP_ZERO الخاصة بـ krealloc().
تم إصلاح هذه المشكلة باستخدام slub_debug_orig_size() بدلاً من ذلك، وهو الفحص الدقيق لمعرفة ما إذا كان الحجم المطلوب يتم تتبعه. لا نحتاج إلى القلق بشأن ما إذا كان وضع "المنطقة الحمراء" مفعلاً أم لا أيضاً. كما تم تحديث وتوسيع التعليق التوضيحي وفقاً لذلك.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.