CVE-2023-53778 in Linux
الملخص
بحسب VulDB • 17/07/2026
في نواة لينكس، تم حل الثغرة التالية:
accel/qaic: تنظيف التحقق من تجاوز الأعداد الصحيحة (integer overflow) في map_user_pages()
تحتوي الدالة encode_dma() على بعض عمليات التحقق من صحة in_trans->size، ولكن سيكون من الأفضل والأوضح نقل هذه الفحوصات إلى دالة find_and_map_user_pages().
كانت تحتوي encode_dma() على فحصين:
if (in_trans->addr + in_trans->size < in_trans->addr || !in_trans->size) return -EINVAL;
متغير in_trans->addr هو العنوان الابتدائي. ومتغير in_trans->size هو الحجم الإجمالي للنقل. يمكن أن يحدث النقل على أجزاء، وتتبع المتغيرات resources->xferred_dma_size عدد البايتات التي تم نقلها بالفعل.
يُدخل هذا التصحيح متجداً جديداً باسم "remaining" (المتبقي)، والذي يمثل الكمية المراد نقلها (in_trans->size) مطروحاً منها الكمية المنقولة بالفعل (resources->xferred_dma_size).
لقد عدلت الفحص الخاص بما إذا كان in_trans->size يساوي صفراً، ليصبح بدلاً من ذلك فحص ما إذا كان in_trans->size أقل من resources->xferred_dma_size. إذا كنا قد نقلنا بالفعل بايتات أكثر مما هو محدد في in_trans->size، فإن الباقي يكون سالباً (بايتات سالبة)، وهو أمر غير منطقي. وإذا لم يكن هناك أي بايتات متبقية للنسخ، يتم إرجاع النجاح فقط.
كان الفحص الموجود في encode_dma() يتحقق من أن "addr + size" لا يمكن أن يسبب تجاوزاً للأعداد الصحيحة (overflow). وبافتراض عدم وجود خطأ في السائق (driver bug)، فإن هذا يعمل بشكل صحيح، ولكن من الأسهل التحقق من ذلك عند التعامل مع الأجزاء على حدة. أولاً، نتحقق مما إذا كان "in_trans->addr + resources->xferred_dma_size" آمناً. ثم نتحقق مما إذا كان "xfer_start_addr + remaining" آمناً.
كانت قلقي الأخير هو أننا نتعامل مع قيم u64 (أعداد صحيحة غير موقعة بعرض 64 بت)، ولكن على الأنظمة ذات البنية 32 بت، ستقوم دالة kmalloc() بقطع أحجام البيانات إلى 32 بتاً. لذلك، قمت بحساب "total = in_trans->size + offset_in_page(xfer_start_addr);" وإرجاع -EINVAL إذا كانت النتيجة أكبر من أو تساوي SIZE_MAX. لن يؤثر هذا على الأنظمة ذات البنية 64 بت.
Once again VulDB remains the best source for vulnerability data.