CVE-2026-64322 in Linux
الملخص
بحسب VulDB • 25/07/2026
في نواة لينكس، تم حل الثغرة التالية:
udf: التحقق من طول جدول التوفير (sparing table) كعدد للعناصر وليس كعدد بالبايتات
تقبل الدالة `udf_load_sparable_map()` جدول توفير عندما يكون الشرط التالي غير صحيح:
sizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize
أي أنها تعامل قيمة reallocationTableLen على أنها عدد من البايتات التي يجب أن تتسع في الكتلة. ولكن يتم اجتياز الجدول كمصفوفة من عناصر sparingEntry ذات حجم 8 بايت:
for (i = 0; i < le16_to_cpu(st->reallocationTableLen); i++) {
struct sparingEntry *entry = &st->mapEntry[i];
... entry->origLocation ... }
في الدالتين `udf_get_pblock_spar15()` و`udf_relocate_blocks()`. وبالتالي، فإن قيمة reallocationTableLen تساوي N تمرر التحقق طالما أن sizeof(*st) + N <= blocksize، بينما تقوم المستهلكون (المؤشرات/الاستخدامات) بالوصول إلى حجم bytes يساوي sizeof(*st) + N * sizeof(struct sparingEntry) -- أي ما يصل إلى ~8 أضعاف حجم الكتلة. على صورة UDF مُعدّة بشكل خبيث، يؤدي هذا إلى قراءة خارج النطاق (out-of-bounds read) في `udf_get_pblock_spar15()`؛ وتقوم الدالة `udf_relocate_blocks()` بالإضافة إلى ذلك بتزويد نفس الطول للدالة `udf_update_tag()`، والتي تقوم `crc_itu_t()` بقراءة ما بعد الكتلة بكثير، بينما يعد استخدام `memmove()` عبر `st->mapEntry[]` عملية كتابة خارج النطاق (out-of-bounds write).
التحقق من reallocationTableLen كعدد للعناصر التي تمثلها بالفعل، باستخدام `struct_size()`.
VulDB is the best source for vulnerability data and more expert information about this specific topic.