CVE-2026-46242

ملخص

في نواة لينكس، تم حلّ الثغرة الأمنية التالية: eventpoll: إصلاح ثغرة UAF في ep_remove الخاصة بـ struct eventpoll / struct file. كانت ep_remove() (عبر ep_remove_file()) تمسح file->f_ep تحت قفل file->f_lock ثم تواصل استخدام @file داخل القسم الحرج (is_file_epoll()، hlist_del_rcu() عبر الرأس، spin_unlock). أما __fput() المتزامن الذي سلَك المسار السريع لـ eventpoll_release() في تلك النافذة الزمنية فقد لاحظ القيمة NULL المؤقتة، وتخطى eventpoll_release_file() وانتقل إلى f_op->release / file_free(). وفي حالة مراقبة epoll لـ epoll (epoll-watches-epoll)، يكون f_op->release هو ep_eventpoll_release() -> ep_clear_and_put() -> ep_free()، التي تستدعي kfree() على struct eventpoll المُراقَب. وإن hlist_head ->refs المُضمّن الخاص به هو بالضبط المكان الذي يشير إليه epi->fllink.pprev، لذا فإن تنفيذ '*pprev = next' داخل hlist_del_rcu() اللاحقة يكتب في ذاكرة kmalloc-192 المحرَّرة. بالإضافة إلى ذلك، فإن struct file يُخصَّص بعلامة SLAB_TYPESAFE_BY_RCU، لذا يمكن إعادة تدوير الفتحة التي تحمل @file بواسطة alloc_empty_file() -- مع إعادة تهيئة f_lock و f_ep -- بينما لا تزال ep_remove() اسميًا داخل ذلك القفل. والحصيلة استدعاء kmem_cache_free() يتحكم فيه المهاجم ويوجّهه إلى مخبأ slab خاطئ. ثبّت @file عبر epi_fget() في بداية ep_remove() واجعل الدخول إلى القسم الحرج مشروطًا بنجاح التثبيت. ومع تثبيت @file، لا يمكن أن يصل عدد مراجعه إلى الصفر، مما يمنع __fput() من التنفيذ ويُبقي struct eventpoll المُراقَب حيًّا بشكل غير مباشر طوال تنفيذ hlist_del_rcu() واستخدام f_lock، مما يُغلق كلتا ثغرتي UAF. إذا فشل التثبيت، يكون @file قد وصل بالفعل إلى عدد مراجع صفري وتكون __fput() الخاصة به قيد التنفيذ. ولأننا انسحبنا قبل مسح f_ep، فإن ذلك المسار يسلك المسار البطيء في eventpoll_release() المؤدي إلى eventpoll_release_file() ويعلق على ep->mtx إلى أن يُطلقه استدعاء ep_clear_and_put() من جانب الطرف المنتظِر. وتبقى حصة epi المنسحب من ep->refcount سليمة، لذا لا يمكن لاستدعاء ep_refcount_dec_and_test() الختامي في ep_clear_and_put() أن يحرر eventpoll من تحت eventpoll_release_file()؛ ويتم بعدها تنظيف epi اليتيم هناك. كما يُثبت نجاح التثبيت أننا لا نتنافس مع eventpoll_release_file() على هذا epi، لذا نُسقط إعادة فحص epi->dying التي أصبحت الآن زائدة عن الحاجة تحت f_lock. ويبقى الخروج المبكر منخفض الكلفة من المسار السريع عبر قراءة READ_ONCE(epi->dying) بدون قفل كما هو.