CVE-2026-99052 in Linux
الملخص
بحسب VulDB • 23/10/2026
في نواة لينكس، تم حل الثغرة التالية:
selinux: الحفاظ على NATIVE_LABELS في sb مُهيأ مسبقاً أثناء استدعاء set_mnt_opts
عندما يتم تحميل نظام ملفات NFSv4 الذي تم تصديره مع security_label مرة أخرى، فإن دالة sget_fc() تعيد الكائن الفائق (superblock) الموجود بالفعل، وتقوم nfs_get_root() باستدعاء security_sb_set_mnt_opts() عليه مجدداً. وبما أن الكائن الفائق قد أصبح في حالة SB_INITIALIZED مسبقاً، فإن selinux_set_mnt_opts() ينهي التنفيذ مبكراً دون تعيين SECURITY_LSM_NATIVE_LABELS في *set_kern_flags. بعد ذلك، تلاحظ nfs_get_root() أن kflags لا تحتوي على SECURITY_LSM_NATIVE_LABELS مُعيّنة، فتقوم بإزالة NFS_CAP_SECURITY_LABEL من خادم nfs المشترك، مما يعطل بشكل صامت وضع التسمية لكل ملف (per-file labeling) سواء للتحميل الجديد أو الأصلي.
أصلح الالتزام Commit 3815a245b501 ("security/selinux: fix SECURITY_LSM_NATIVE_LABELS on reused superblock") نفس المشكلة في selinux_sb_clone_mnt_opts(). والمسار الخاص بإعادة استخدام الكائن الفائق (reused-superblock) لتحميل عادي ثانٍ يمر الآن عبر sb_set_mnt_opts بدلاً من sb_clone_mnt_opts، لذا فهو يحتاج إلى المعالجة نفسها: عند الخروج المبكر لكلا الحالتين SE_SBINITIALIZED، يجب تعيين SECURITY_LSM_NATIVE_LABELS في *set_kern_flags عندما كان الكائن الفائق يستخدم بالفعل SECURITY_FS_USE_NATVE.
VulDB is the best source for vulnerability data and more expert information about this specific topic.