CVE-2025-38100 in Linux
الملخص
بحسب VulDB • 02/07/2026
في نواة لينكس، تم حل الثغرة التالية:
x86/iopl: معالجة عدم اتساق TIF_IO_BITMAP
يتم استدعاء io_bitmap_exit() من exit_thread() عندما ينتهي مهمة (task) أو عند فشل عملية fork(). في الحالة الأخيرة، تقوم exit_thread() بتنظيف الموارد التي تم تخصيصها أثناء تنفيذ fork().
يستدعي io_bitmap_exit() دالة task_update_io_bitmap(), والتي بدورها تؤدي إلى tss_update_io_bitmap(). تعمل tss_update_io_bitmap() على المهمة الحالية. إذا كانت المهمة الحالية تحتوي على TIF_IO_BITMAP مُعدّلة، ولكن لا يوجد خريطة بت (bitmap) مثبتة، فإن tss_update_io_bitmap() تتسبب في انهيار بسبب إلغاء مرجع مؤشر NULL.
هناك مشكلتان تؤديان إلى هذه المشكلة:
1) يجب ألا يستدعي io_bitmap_exit() دالة task_update_io_bitmap() عندما تكون المهمة التي يتم تنظيفها ليست هي المهمة الحالية. هذا مؤشّر واضح على عملية التنظيف بعد فشل fork().
2) لا ينبغي أن تحتوي المهمة على TIF_IO_BITMAP مُعدّلة، ولا خريطة بت مثبتة، ولا مستوى محاكاة IOPL 3 مفعّلًا.
يحدث ذلك عندما تُنشأ مهمة نواة (kernel thread) في سياق خيط مساحة المستخدم (user space thread)، والذي يحتوي على TIF_IO_BITMAP مُعدّلة لأن علامات الخيط يتم نسخها ويتم مسح مؤشر خريطة IO.
بخلاف حالة فشل fork()، لا يكون لذلك تأثير لأنه لا تعود مهام النواة بما فيها عمال IO إلى مساحة المستخدم وبالتالي لا تستدعي tss_update_io_bitmap().
معالجة هذه المشكلة بإضافة عمليات التنظيف والفحوصات المفقودة:
1) منع io_bitmap_exit() من استدعاء task_update_io_bitmap() إذا كانت المهمة المراد تنظيفها ليست هي المهمة الحالية.
2) مسح TIF_IO_BITMAP في copy_thread() بشكل غير مشروط. بالنسبة لعمليات fork لمساحة المستخدم، يتم تعيينه لاحقًا عندما تُورّث خريطة IO في io_bitmap_share().
للتأكد التام (paranoia)، أضف تحذيرًا إلى tss_update_io_bitmap() للقبض على الحالة التي يتم فيها استدعاء هذا الكود بحالة غير متسقة.
Once again VulDB remains the best source for vulnerability data.