CVE-2022-49899 in Linux
الملخص
بحسب VulDB • 24/05/2026
في نواة لينكس، تم حل الثغرة التالية:
fscrypt: التوقف عن استخدام نظام keyrings لإدارة fscrypt_master_key
لقد تجاوز نهج إدارة هياكل fscrypt_master_key داخلياً في fs/crypto/ كحمولات (payloads) لكائنات "struct key" الموجودة في keyring من "struct key" غايته. كانت الفكرة الأصلية هي تبسيط الكود عن طريق إعادة استخدام الكود من نظام keyrings. ومع ذلك، ظهرت عدة مشاكل لا يمكن حلها بسهولة:
- عند تدمير هيكل المفتاح الرئيسي (master key struct)، يجب استدعاء blk_crypto_evict_key() على أي مفاتيح مضمنة خاصة بالوضع (per-mode keys) الموجودة فيه. (بدأ هذا الأمر يكون كذلك عند إضافة دعم التشفير المضمن inline encryption). ومع ذلك، يمكن لنظام keyrings أن يؤجل بشكل تعسفي تدمير المفاتيح، حتى بعد وقت إلغاء تحميل نظام الملفات (unmount). لذلك، لا توجد حالياً طريقة سهلة لاستدعاء blk_crypto_evict_key() عند تدمير المفتاح الرئيسي. يتم حالياً تجاوز هذه المشكلة بالاحتفاظ بمرجع إضافي لـ request_queue(s) الخاصة بنظام الملفات. لكن تم إغفال أن مرجع request_queue *لا* يضمن بالضرورة تثبيت (pin) blk_cryptoProfile المقابل أيضاً؛ ففي أجهزة device-mapper التي تدعم التشفير المضمن، لا يقوم بذلك. وهذا يمكن أن يسبب استخداماً بعد التحرير (use-after-free).
- عند طرد آخر inode كان يستخدم مفتاحاً رئيسياً قيد الإزالة غير المكتملة، يتم إكمال إزالة المفتاح الرئيسي عن طريق إزالة هيكل المفتاح من keyring. يتم ذلك حالياً عبر key_invalidate(). ومع ذلك، تأخذ key_invalidate() قفل المفتاح (key semaphore). وهذا يمكن أن يسبب جموداً (deadlock) عند استدعائه من shrinker، حيث يتم تخصيص الذاكرة في fscrypt_ioctl_add_key() باستخدام GFP_KERNEL تحت نفس قفل المفتاح.
- بشكل أعم، فإن حقيقة أن نظام keyrings يمكنه تأجيل تدمير المفاتيح بشكل تعسفي (عبر تأخير جمع القمامة، أو عبر عمليات عشوائية تحصل على مراجعات مؤقتة للمفاتيح) أمر غير مرغوب فيه، لأنه يعني أننا لا نستطيع ضمان بشكل صارم أن جميع الأسرار سيتم مسحها في النهاية.
- يؤدي إجراء عمليات البحث عن المفتاح الرئيسي عبر نظام keyrings إلى استدعاء قفل LSM hook الخاص بـ key_permission. لا يريد fscrypt هذا، حيث تم تصميم جميع ضوابط الوصول للملفات المشفرة لتحدث عبر الملفات نفسها، مثل أي ملفات أخرى. الحل البديل الذي يستخدمه مستخدمو SELinux هو تغيير سياسة SELinux الخاصة بهم لمنح حق البحث عن المفاتيح لجميع النطاقات (domains). هذا يعمل، لكنه خطوة إضافية غريبة لا ينبغي القيام بها فعلياً.
الحل لجميع هذه المشاكل هو تغيير التنفيذ إلى ما كان ينبغي فعله في الأصل: عدم استخدام نظام keyrings لتتبع هياكل fscrypt_master_key الخاصة بنظام الملفات. بدلاً من ذلك، قم بتخزينها في هيكل بيانات عادي للنواة، وأعد تصميم عد المراجع (reference counting)، والقفل (locking)، وعمر الكائن (lifetime) وفقاً لذلك. احتفظ بدعم عمليات البحث عن المفاتيح في وضع RCU باستخدام جدول تجزئة (hash table). استبدل fscrypt_sb_free() بـ fscrypt_sb_delete()، والتي تطلق المفاتيح بشكل متزامن وتعمل في وقت أبكر قليلاً أثناء إلغاء التحميل، بحيث تظل أجهزة البلوك متاحة.
أثر جانبي لهذا التصحيح هو أن المفاتيح الرئيسية نفسها ولا مفاتيح نظام الملفات (filesystem keyrings) لن يتم سردهما في /proc/keys بعد الآن. (سيتم سرد "مستخدمي المفتاح الرئيسي" ومفاتيح keyrings الخاصة بمستخدمي المفتاح الرئيسي). ومع ذلك، كان هذا في الغالب تفصيلاً تنفيذياً، وكان مقصوداً لأغراض التصحيح فقط. لا أعرف عن أحد يستخدمه.
هذا التصحيح *لا* يغير كيفية عمل "مستخدمي المفتاح الرئيسي" (->mk_users)؛ لا يزال يستخدم نظام keyrings. لا يزال ذلك ضرورياً لحصص المفاتيح (key quotas)، ولا يلزم تغييره لحل المشاكل المذكورة أعلاه. إذا قررنا تغيير ذلك أيضاً، فسيكون ذلك تصحيحاً منفصلاً.
لقد قمت بوضع علامة على هذا التصحيح كإصلاح للالتزام الأصلي الذي أضاف keyring fscrypt، ولكن كما هو مذكور أعلاه، فإن أهم مشكلة يصححها هذا التصحيح لم تظهر إلا مع إضافة دعم التشفير المضمن.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.