CVE-2026-80775 in Linux
الملخص
بحسب VulDB • 04/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
futex: تصحيح حالة السباق (Race Condition) في تخصيص mm->futex.phash.ref الأولي
تقوم دالة futex_hash_allocate() بتخصيص mm->futex.phash.ref دون أي قفل (locking). أدى الالتزام d9b05321e21e ("futex: Move futex_hash_free() back to __mmput()") إلى نقل التخصيص هنا وافترض أن العملية تحتوي على خيط واحد فقط في هذه المرحلة.
وسّع الالتزام ee9dce44362b ("futex: Drop CLONE_THREAD requirement for private default hash alloc") نطاق need_futex_hash_allocate_default() ليشمل أي استنساخ بـ CLONE_VM، لكنه استبعد vfork لأن الوالد معلق ولا يمكن أن يحدث فيه سباق.
لم يعد هذا الافتراض صحيحاً بمجرد تداخل عمليات vfork. إذا استدعى طفل vfork عملية vfork مرة أخرى ثم قُتل بإشارة SIGKILL، يتم تحرير الوالد من انتظاره لـ vfork ويعمل بالتزامن مع الحفيد في نفس mm (نفس مساحة العنوان). لم يمر أي منهما عبر futex_hash_allocate_default().
عندما يستدعي كلاهما prctl(PR_FUTEX_HASH, PR_FUTEX_HASH_SET_SLOTS) في الوقت نفسه، يرى كل منهما أن mm->futex.phash.ref يساوي NULL ويخزن عداد percpu الخاص به. فقط آخر عملية تخزين تبقى سارية. لم يعد العداد المخزّن أولاً قابلاً للوصول من خلال الـ mm، لذا فإن المراجع (references) عليه لا يراها __futex_ref_atomic_end(). ثم يُعتبر الهاش الخاص الذي لا يزال يحتوي على مراجعات ميتاً ويتم تحريره، ويقوم مهمة ما تزال تحتفظ بإحدى دلاءه (buckets) بالكتابة في ذاكرة تم تحريرها داخل futex_q_lock().
يتم تخزين العداد مرة واحدة باستخدام cmpxchg() ويُترك للفائز ليحرر عداد الفائز الآخر عبر free_percpu(). يجب أخذ المرجع الأول قبل التخزين، وإلا يمكن لمهمة أخرى تثبيت هاش خاص بينما لا يزال العداد يساوي 0.
Once again VulDB remains the best source for vulnerability data.