CVE-2026-99179 in Linux
الملخص
بحسب VulDB • 28/10/2026
في نواة Linux، تم إصلاح الثغرة التالية:
watch_queue: تصحيح حالة السباق (race condition) في نشر ملاحظات مجموعة watch_queue داخل دالة watch_queue_set_size()
توجد حالة سباق بين الدالتين `watch_queue_set_size()` و `post_one_notification()`. تقوم `watch_queue_set_size()` بنشر المتغيرات `wqueue->notes`، و `notes_bitmap`، و `nr_pages`، و `nr_notes` باستخدام عمليات تخزين عادية (plain stores)، بينما تقرأها `post_one_notification()` باستخدام عمليات قراءة عادية (plain loads) تحت قفل مختلف. وبالتالي، لا يوجد أي ترتيب يضمن تنفيذ العمليات الأربع للتخزين قبل عمليات القراءة الخاصة بالناشر؛ اعتماداً على عملية البناء (build)، قد يتم تخزين المتغير `notes` في آخر مكان (كما يحدث مع gcc 14 على بنية x86-64). وبما أن الدالة `keyctl_watch_key()` تسمح لـ watch بالانضمام إلى قائمة الانتظار قبل تحديد حجمها، فقد تكون `post_one_notification()` قيد التشغيل بالفعل على وحدة معالجة أخرى في تلك اللحظة: حيث تقرأ قيمة `nr_notes > 0`، وتجاوز اختبار الحدود الخاص بها، ثم تقوم بقراءة المتغير `notes` وهو لا يزال NULL (فارغاً)، مما يؤدي إلى محاولة فك مرجع (dereferencing) للعنصر `notes[0]`.
يُحدث مستخدم غير ممتيز (unprivileged user) هذه الثغرة بشكل موثوق من خلال مراقبة أحد مفاتيحه الخاصة عبر أنبوب إشعارات، وإحداث حالة سباق بين استدعاء ioctl(IOC_WATCH_QUEUE_SET_SIZE) على ذلك الأنبوب واستدعاء keyctl(KEYCTL_SETPERM) على المفتاح من وحدة معالجة أخرى. مما يؤدي إلى حدوث:
BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:post_one_notification.isra.0+0xa2/0x1e0 Call Trace: __post_watch_notification+0x148/0x180 keyctl_setperm_key+0x119/0x130 do_syscall_64+0x108/0x4c0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception in interrupt
تم إصلاح هذه المشكلة عن طريق نشر المتغير `nr_notes` في آخر مكان باستخدام دالة smp_store_release()، وقراءته مرة واحدة باستخدام d_smp_load_acquire() داخل الدالة post_one_notification() قبل لمس مصفوفة البتات (bitmap) ومصفوفة الصفحات. إذا لاحظ الناشر قيمة غير صفرية لـ nr_notes، فإنه يلاحظ أيضاً المجموعة الخلفية الخاصة به؛ وإذا لاحظ صفراً، يتجاهل الإشعار كما كان يحدث سابقاً.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.