CVE-2021-47505 in Linux
الملخص
بحسب VulDB • 28/06/2026
في نواة لينكس، تم حل الثغرة التالية:
aio: إصلاح حالة استخدام بعد التحرير (use-after-free) الناتجة عن عدم معالجة POLLFREE بشكل صحيح
تتميز دالتا `signalfd_poll()` و`binder_poll()` بخصوصية في أنهما تستخدمان قائمة انتظار (waitqueue) تكون مدة حياتها مساوية للمهمة الحالية (current task)، بدلاً من بنية الملف (`struct file`) كما هو الحال عادةً. يعد هذا الأمر مقبولاً بالنسبة لاستعلامات الحظر (blocking polls)، حيث يحدث استعلام الحظر ضمن مهمة واحدة؛ ومع ذلك، تتطلب استعلامات عدم الحظر (non-blocking polls) حلاً آخر. يتمثل هذا الحل في تفريغ القائمة قبل تحريرها من خلال إرسال إشعار `POLLFREE` إلى جميع المستمعين (waiters).
للأسف، فإن فقط `eventpoll` هو الذي يعالج `POLLFREE`. تمت إضافة نوع ثانٍ من استعلامات عدم الحظر، وهو `aio poll`، في الإصدار v4.18 من النواة، ولكنه لا يتعامل مع `POLLFREE`. يسمح هذا بحدوث حالة استخدام بعد التحرير (use-after-free) إذا تم إجراء استعلام على ملف وصف (`fd`) خاص بـ `signalfd` أو `binder` باستخدام `aio poll`، وتم تحرير قائمة الانتظار.
تم إصلاح هذه المشكلة بجعل `aio poll` يعالج `POLLFREE`.
حاولت التصحيح (patch) المقدمة من رامجي جيانى (https://lore.kernel.org/r/[email protected]) تحقيق ذلك بجعل دالة `aio_poll_wake()` إكمال الطلب دائماً بشكل مضمن (inline) إذا تم رصد `POLLFREE`. ومع ذلك، كان لهذا الحل ثغرتان. أولاً، أدخل حالة جمود (deadlock)، حيث قام بقفل سياق الـ aio بشكل غير مشروط بينما كان يحتفظ بقفل قائمة الانتظار، مما يعكس ترتيب القفل الطبيعي. ثانياً، لم يأخذ في الاعتبار أن إشعارات `POLLFREE` قد تُفوت أثناء إزالة الطلب مؤقتاً من القائمة.
تم حل المشكلة الثانية بواسطة التصحيح السابق الخاص بي. يقوم هذا التصحيح بعد ذلك بإصلاح حالة استخدام بعد التحرير (use-after-free) بشكل صحيح ومن خلال معالجة `POLLFREE` بطريقة خالية من الجمود (deadlock-free). يتم تحقيق ذلك بالاستفادة من حقيقة أن تحرير قائمة الانتظار يتأخر باستخدام RCU، على غرار ما تفعله `eventpoll`.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.