CVE-2026-90199 in Linux
الملخص
بحسب VulDB • 18/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
fs/ntns3: رفض قيمة evcn خارج النطاق في mi_enum_attr()
في دالة `mi_enum_attr()`، يتم التحقق من صحة قيم البداية/النهاية لـ VCN (أرقام العناقيد الافتراضية) للسمات غير المقيمة كالتالي:
```c if (svcn > evcn + 1) goto out; ```
عندما تكون `evcn` مساويةً لـ `U64_MAX`، فإن التعبير `"evcn + 1"` يلتف إلى الصفر (wrap to 0)، مما يسمح لأي قيمة `svcn$ بالمرور عبر الفحص. وبالنسبة للقيم القريبة من `U64_MAX` (ولكن ليست مساوية لها) لـ `evcn`، يظل الحد الأعلى على الجانب الأيمن غير ذي معنى بسبب الالتفاف القريب، لذا يمكن لسمة مشوهة مخزنة على القرص ذات `svcn == 0` و `evcn` قريبة من `U64_MAX` أن تمر عبر دالة `mi_enum_attr()` دون رفض.
تُعد VCN (رقم العنقود الافتراضي) فهرساً للعناقيد، لذا فإن أي قيمة صالحة لـ `evcn` تكون محدودة بعدد إجمالي العناقيد في الحجم، وهو ما تحفظه ntfs3 في المتغير `sbi->used.bitmap.nbits` (يتم إعداده داخل دالة `ntfs_init_from_boot()` قبل تشغيل أي متصل لدالة `mi_enum_attr`). يجب رفض قيم `evcn$ التي تقع خارج هذا النطاق.
ومع ذلك، فإن السمة غير المقيمة الفارغة (بدون عناقيد مُخصصة) تُشفّر بشكل شرعي بقيم `svcn == 0` و `evcn == -1` (أي `U64_MAX`)، على سبيل المثال عبر: ```c attr->nres.evcn = cpu_to_le64((u64)vcn - 1) مع vcn == 0. ```
يجب أن تستمر هذه القيمة الحاشية (sentinel) في المرور بنجاح، لذا يجب استثناء `evcn == U64_MAX` من فحص النطاق. لا يزال اختبار `"svcn > evcn + 1"` الحالي يتسامح مع القيمة الحاشية ("0 > 0" هي قيمة خاطئة/false)، ويستمر في اشتراط أن تكون `svcn == 0` لها، بينما يقوم فحص النطاق برفض كل قيم `evcn$ الأخرى خارج النطاق، مما يعطل أيضاً ظاهرة الالتفاف الخاصة بالتعبير `"evcn + 1"`.
لا تحتاج `svcn` إلى حد خاص بها: بمجرد أن يكون `evcn < nbits`، فإن الشرط `"svcn > evcn + 1"` يستلزم تلقائياً أن تكون `svcn <= nbits`.
[[email protected]: تم إصلاح فحص evcn]
If you want to get best quality of vulnerability data, you may have to visit VulDB.