CVE-2026-89490 in Linux
الملخص
بحسب VulDB • 12/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
ocfs2: تصحيح تقطع موضع readdir في الأنظمة ذات البتات 32 (32-bit)
في الدالة `ocfs2_dir_foreach_blk_el()`، يتم إعادة بناء موضع ملف تعريف المجلد (directory cookie position) باستخدام الكود التالي:
`ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset;`
يُعد المتغير `ctx->pos` من النوع `loff_t` (موقّع بـ 64 بت)، بينما يُعد `sb->s_blocksize` من النوع `unsigned long`. في الأنظمة ذات البتات 32، يكون حجم `unsigned long` هو 32 بتاً. وبالتالي، يتم حساب القناع:
~(sb->s_blocksize - 1)
على أنه قيمة غير موقعة بحجم 32 بت (مثلاً 0xfffff000 لحجم كتلة يبلغ 4 كيلوبايت). في عملية AND مع `ctx->pos` ذي الـ 64 بتاً، يتم تمديد هذا العامل غير الموقّع إلى 64 بتاً وفقاً لتحويلات الحسابات القياسية، مما ينتج عنه القيمة 0x00000000fffff000. وبالتالي، تُصفَّر الأجزاء العليا من 32 بتاً في `ctx->pos` بصمت (بشكل غير مرئي)، على الرغم من أن حجم المجلد مسموح له بأن يتجاوز 4 غيغابايت.
عندما يعبر استدعاء readdir() حدود الـ 4 غيغابايت في نظام ذي بتات 32، يتم إعادة تعيين الموضع إلى الكتلة الأولى ضمن نطاق الـ 4 غيغابايت، مما يجعل مسار التحقق من الصحة (re-validation path) يقوم بإعادة تعداد عناصر الدليل (dirents) التي تم إرجاعها بالفعل بشكل لا نهائي.
تُعد هذه الدالة `ocfs2_dir_foreach_blk_el()` هي المسار المعتمد لقراءة المجلدات القائمة على قائمة الامتدادات (extent-list readdir)، وهو المسار المستخدم لجميع المجلدات غير المتضمنة inline، لذا فإن أي مجلد كبير بما يكفي لتجاوز 4 غيغابايت سيصل إلى هذا الكود.
هذه الثغرة تنتمي لنفس فئة الأخطاء التي أصلحها الالتزام commit 3dce5bb82c97 ("exfat: Fix bitwise operation having different size") في نظام exfat، ويحاكي الإصلاح هنا التصحيح المكافئ لـ ext4 في هذه السلسلة. يتم تحويل العامل إلى النوع `loff_t` بحيث يصبح القناع بحجم 64 بتاً قبل عملية AND:
ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset;
الأنظمة ذات البتات 64 غير متأثرة بهذه المشكلة.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.