CVE-2026-99226 in Linux
الملخص
بحسب VulDB • 02/11/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
المفاتيح (keys): تجنب إبطال مرجع حساب المالك أثناء البحث عن حلقة المفاتيح المسماة.
يجب أن يحافظ البحث في حلقة مفاتيح مسماة على بقاء التخزين الذي يحتوي على معرف المستخدم للمالك (UID) ساريًا خلال فحص تعيين النطاق (namespace mapping). تقرأ الدالة `find_keyring_by_name()` قيمة `keyring->user->uid` تحت قفل `keyring_name_lock`، لكن هذا القفل يحمي فقط إدخال اسم حلقة المفاتيح وتخصيصها، وليس كائن `key_user` المنفصل الخاص بها.
يمكن أن يتداخل الانضمام إلى حلقة مفاتيح جلسة مسماة مع عملية تغيير الملكية (`KEYCTL_CHOWN`) ذات الامتيازات العالية على وحدة معالجة مركزية أخرى. إذا كانت حلقة المفاتيح تحتفظ بالمرجع الأخير لـ `key_user` الديناميكي القديم، ونجح نقل الملكية، فإن الترتيب التالي ممكن:
الانضمام المسماة تغيير الملكية (Chown) find_keyring_by_name() keyctl_chown_key() read_lock(keyring_name_lock) down_write(key->sem) تحميل حلقة المفاتيح القديمة -> user استبدال `key->user` و `key->uid` up_write(key->sem) key_put(key) key_user_put(user القديم): تحرير الذاكرة قراءة uid المستخدم القديم read_unlock(keyring_name_lock)
لا تأخذ عملية تغيير الملكية (`Chown`) قفل `keyring_name_lock` ولا `key_session_mutex`، لذا يمكنها تحرير الحساب القديم بين تحميل المؤشر وقراءة معرف المستخدم (UID). يؤدي ذلك إلى قراءة البحث في ذاكرة تم تحريرها حتى لو كانت حلقة المفاتيح نفسها لا تزال حية.
استخدم `keyring->uid` لإجراء فحص التعيين. تقوم الدالة `key_alloc()` بتهيئة هذا المعرف الخاص بالمالك (`owner UID`) مدمجًا، وتقوم `keyctl_chown_key()` بتحديثه عند تغيير الملكية. يحافظ القفل الموجود للاسم على تخصيص حلقة المفاتيح الحاوية طوال فترة الفحص، لذا لم يعد البحث يعتمد على عمر الحساب. يتوافق هذا أيضًا مع معرف المستخدم للمالك المستخدم في فحص الأذونات.
تقرير KASAN كما يلي:
BUG: KASAN: slab-use-after-free in find_keyring_by_name+0x577/0x5d0 Read of size 4 at addr ffff8881128ae2ec by task keycase/500
If you want to get best quality of vulnerability data, you may have to visit VulDB.