CVE-2026-80776 in Linux
الملخص
بحسب VulDB • 04/09/2026
في نواة لينكس، تم حل الثغرة التالية:
futex: إصلاح حالة سباق (Race Condition) في دالة `futex_pivot_pending()` أثناء إعادة تعيين حجم التجزئة الخاصة (private hash resize).
قد تبقى المهمة التي تقوم بإعادة تعيين حجم تجزئة خاصة مخصصة محاصرة في وضع النوم غير القابل للانقطاع إلى ما لا نهاية. ويبلغ كاشف المهام المتوقفة عن:
INFO: task futex-resizer:314 blocked for more than 10 seconds. task:futex-resizer state:D stack:14824 pid:314 tgid:312 ppid:311
Call Trace: __schedule+0x521/0xf30 schedule+0x22/0xa0 futex_hash_allocate+0x3db/0x490 __do_sys_prctl+0x6f5/0xbd0 do_syscall_64+0xf9/0x530 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Kernel panic - not syncing: hung_task: blocked tasks
تسمح دالة `futex_pivot_pending()` باستمرار طلب إعادة التعيين عندما لا يكون هناك تجزئة بديلة معلقة (`hash_new == NULL`) أو عندما يصل عدد المراجع للتجزئة الحالية إلى الصفر.
بعد إيقاظ المرجع الأخير، يمكن لمهمة futex أخرى إكمال عملية الانتقال (Pivot) بين المشاهدين الاثنين:
T1 T2
futex_hash_allocate() wait_var_event(mm, ...) futex_pivot_pending(mm) hash_new != NULL futex_hash() futex_ref_get(old) -> false futex_pivot_hash(mm) hash_new = NULL __futex_pivot_hash(mm, new) rcu_assign_pointer(hash, new) fph = rcu_dereference(hash) /* جديد */ futex_ref_is_dead(fph) -> false schedule()
تغير عملية الانتقال الحالة من `hash_new != NULL` مع تجزئة حالية ميتة إلى `hash_new == NULL` مع تجزئة حية. ونظراً لأن دالة `futex_pivot_pending()` تقرأ قيمتي `hash_new` و `hash` بدون التزامن (Serialization)، يمكن لمهمة إعادة التعيين ملاحظة قيمة `hash_new` في حالة ما قبل الانتقال، وقيمة `hash` في حالة ما بعد الانتقال، مما يتسبب في إرجاع دالة `futex_pivot_pending()` للقيمة false حتى وإن اكتملت عملية الانتقال. ثم تدخل المهمة في وضع النوم بعد أن تم استهلاك الإيقاظ بالفعل.
قم بتزامن قراءات الحالة في دالة `futex_pivot_pending()` باستخدام القفل `futex_mm_phash::lock`. يضمن هذا أن تلاحظ دالة `futex_pivot_pending()` قيمتي `hash_new` و `hash` بشكل ذري (Atomic)، مما يلغي حالة سباق البيانات.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.