CVE-2026-99181 in Linux
الملخص
بحسب VulDB • 28/10/2026
في نواة لينكس، تم حل الثغرة التالية:
autofs: تجاهل أخطاء الإشعارات الناتجة عن أنبوب (pipe) مستبدل
تأخذ الدالة `autofs_notify_daemon()` مرجعاً إلى أنبوب الإشعارات الحالي تحت قفل `wq_mutex`، ثم تزيل القفل قبل كتابة الطلب. قد تتوقف عملية الكتابة بينما يدخل الخادم (daemon) في وضع "catatonic" ويثبّت أنبوباً بديلاً.
إذا تم إغلاق قارئ الأنبوب القديم بعد ذلك، فإن الكتابة المؤجلة تُرجع قيمة `-EPIPE`، ويدخل مسار الخطأ العام مرة أخرى في وضع "catatonic". يؤثر هذا الانتقال على حالة superblock الحالية، ويقفل الأنبوب البديل، ويحرر طوابير الانتظار (wait queues) الخاصة بجيل الخادم الجديد.
ادخل إلى وضع "catatonic" فقط عندما يكون الأنبوب الذي فشل لا يزال هو الأنبوب الحالي. افصل الانتقال المعتمد بالفعل على القفل بحيث تكون عملية التحقق من الهوية وتغيير الحالة ذرية (atomic) فيما يتعلق بأي استبدال آخر.
تم إعادة إنتاج هذه المشكلة في الإصدار `v7.3-rc5-337-gff47652a4b66c` داخل ضيف QEMU محلي. أدى البحث الذي أجراه مستخدم غير ممتياز بمعرف المستخدم (UID) 65534 إلى ملء أنبوب الحزم القديم قبل إعادة التشغيل العادية لوضع CATATONIC/SETPIPEFD. على النواة غير المعدلة، تلقى الأنبوب الجديد إشارة HUP، وفشل كل من بحث الضحية المعلق وبحث لاحق بـ ENOENT في حالتي تشغيل للتثبيت الطازج (fresh-mount) من أصل حالتين.
مع هذا التغيير، بقي الأنبوب الجديد نشطاً، وتلقى طلباً سليماً بحجم 304 بايت، وأكملت عمليات البحث عن الضحايا بنجاح في حالتي تشغيل من أصل حالتين. نجحت اختبارات التحكم الخاصة بالبحث العادي وإعادة التشغيل دون كاتب محجوز (blocked-writer). لم يُلاحظ أي تشخيص لـ KASAN أو oops أو عداد المراجع (refcount) أو قفل. تتوفر أداة إعادة إنتاج المصدر والسجلات المحلية الكاملة بشكل خاص عند الطلب.
الأثر المُظهر محدود بإنكار خدمة autofs المشتركة أثناء إعادة تشغيل الخادم المشروعة. لم تُرصد أي فساد في الذاكرة، تسرب للمعلومات، تصعيد للصلاحيات، أو آلية لتنفيذ الأكواد (code execution primitive).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.