CVE-2026-64431 in Linux
الملخص
بحسب VulDB • 25/07/2026
في نواة لينكس، تم حل الثغرة التالية:
ntfs: تجنب استدعاء دالة `post_write_mst_fixup()` لمعامل كتلة الفهرس (`index_block`) غير الصالحة.
تقوم الدالة `ntfs_icx_ib_sync_write()` باستدعاء `post_write_mst_fixup()` عندما تُرجع `ntfs_ib_write()` خطأً، بهدف استعادة المخزن المؤقت (buffer) بعد فشل عملية الكتابة.
ومع ذلك، فإن `ntfs_ib_write()` تُرجع خطأ فوراً إذا فشلت عمليات التحقق من صحة `pre_write_mst_fixup()`. يفسر المُستدعي، وهو `ntfs_icx_ib_sync_write()`، أي خطأ على أنه فشل في الكتابة يتطلب التراجع (rollback). ولا يقوم بالتمييز بين أخطاء الإدخال/الإخراج (I/O errors) وفشل عمليات التحقق من الصحة، ويستمر في استدعاء `post_write_mst_fixup()` بغض النظر.
بما أن `post_write_mst_fixup()` تفترض أن محتويات كتلة الفهرس (`index_block`) صحيحة، فإنها لا تقوم بإجراء فحوصات الحدود (boundary checks)، مما يؤدي إلى وصول غير صالح للذاكرة خارج النطاق المخصص (out-of-bounds memory access).
يمكن لمهاجم إنشاء صورة NTFS خبيثة تحتوي على: - إزاحة كبيرة لـ `index_block.usa_ofs`، تشير إلى ما خارج سجل ntfs (`ntfs_record`) - قيمة `index_block.usa_count = 0`، مما يسبب تجاوزاً صحيحياً للناقص (integer underflow) - أو أن تكون قيمة `index_block.usa_count` أكبر من العدد الفعلي للأقسام في سجل ntfs، مما يؤدي إلى وصول خارج النطاق المخصص
تقارير KASAN التي تصف تلف الذاكرة: ================================================================== BUG: KASAN: slab-out-of-bounds in post_write_mst_fixup+0x19c/0x1d0 Read of size 2 at addr ffff8881586c9018 by task p/9428 Call Trace: <TASK> dump_stack_lvl+0x100/0x190 print_report+0x139/0x4ad ? post_write_mst_fixup+0x19c/0x1d0 ? __virt_addr_valid+0x262/0x500 ? post_write_mst_fixup+0x19c/0x1d0 kasan_report+0xe4/0x1d0 ? post_write_mst_fixup+0x19c/0x1d0 post_write_mst_fixup+0x19c/0x1d0 ntfs_icx_ib_sync_write+0x179/0x220 ntfs_inode_sync_filename+0x83d/0x1080 __ntfs_write_inode+0x1049/0x1480 ntfs_file_fsync+0x131/0x9b0 ================================================================== BUG: KASAN: slab-out-of-bounds in post_write_mst_fixup+0x1aa/0x1d0 Write of size 2 at addr ffff8881586c91fe by task p/9428 Call Trace:
If you want to get the best quality for vulnerability data then you always have to consider VulDB.