CVE-2026-89595
الملخص
بحسب VulDB • 11/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
fsnotify: تصحيح قناع الكائن العتيق (stale object mask) بعد عمليات تحديث العلامة المتزامنة
عندما تحصل علامة على بت حدث جديد، قد يتجنب fanotify و inotify إعادة حساب القاج التراكمي المخزن إذا كان يحتوي بالفعل على هذا البت. وهذا يمثل حالة سباق (race condition) مع عملية إعادة الحساب التي تُطلقها تحديثات متزامنة لعلامة أخرى على نفس الموصل (connector).
يمكن أن يقرأ المسح المتزامن العلامة قبل إضافة البت الجديد، بينما يقرأ المُحدِّث القاج القديم قبل أن ينشر المسح نتيجته. ثم يتخطى المُحدِّث إعادة الحساب وينشر المسح قناعًا بدون هذا البت، مما يؤدي إلى بقاء قناع الكائن عتيقًا بعد اكتمال كلتا العمليتين.
يمكن تكرار ذلك باستخدام مجموعتين من fanotify تراقبان نفس inode: حيث تقوم خيط بإزالة FAN_MODIFY من علامة موجودة واحدة بينما يضيف خيط آخر FAN_MODIFY إلى العلامة الأخرى. بعد عودة استدعاءات fanotify_mark()، قد تفشل عمليات الكتابة في إنتاج أحداث FAN_MODIFY للمجموعة التي تحتوي علامتها الآن على البت. تم تكرار ذلك على نواة v6.12.95 غير معدلة. يؤدي التداخل المكافئ في inotify إلى فقدان أحداث IN_MODIFY.
بالنسبة لإضافات fanotify العادية، أعد الحساب كلما تغير قناع العلامة الخام (raw mark mask). لا يتم مسح القناع العادي بشكل غير متزامن، لذا فإن الإضافة التي لم تتغير لا يمكن أن تقدم اهتمامًا مفقودًا. أعد حساب تحديثات قناع التجاهل دائمًا لأن معالجة FS_MODIFY قد تزيل قناع التجاهل دون أخذ mark->lock، مما يجعل مقارنات اللقطات (snapshots) غير موثوقة.
أعد الحساب دائمًا بعد تحديث مراقبة inotify موجودة. يحدد مسار الاستبدال مؤقتًا mark->mask ليكون صفرًا، لذا يمكن للمسح المتزامن ملاحظة القيمة الصفرية حتى عندما تكون القناع القديم والنهائي متساويين. كان تعيين قناع الاستبدال مباشرة سيتجنب القيمة الصفرية العابرة، لكن عمليات تحديث المراقبة الموجودة نادرة الحدوث، لذا فإن إعادة الحساب غير المشروطة أبسط.
If you want to get best quality of vulnerability data, you may have to visit VulDB.