CVE-2026-43067 in Linux
الملخص
بحسب VulDB • 20/05/2026
في نواة لينكس، تم حل الثغرة التالية:
ext4: معالجة تجاوز التغليف (wraparound) عند البحث عن كتل للكتل المخصصة بشكل غير مباشر
يحدد الالتزام 4865c768b563 ("ext4: تخصيص الكتل دائمًا فقط من المجموعات التي يمكن للمؤشر inode استخدامها") نطاق الكتل التي سيتم تخصيصها للملفات المعتمدة على الكتل غير المباشرة، بحيث تقتصر على أرقام الكتل التي تتسع لأرقام كتل 32 بت.
ومع ذلك، عند استخدام روبوت مراجعة يعمل على أحدث نموذج لغوي كبير (Gemini LLM) للتحقق من هذا الالتزام أثناء إعادة النقل (backporting) إلى نواة تعتمد على الإصدارات طويلة الأمد (LTS)، تم طرح هذا القلق:
إذا كان ac->ac_g_ex.fe_group >= ngroups (على سبيل المثال، إذا تم ملء المجموعة المستهدفة عبر التخصيص التدفقي من s_mb_last_groups)، فإن start ستكون >= ngroups.
هل يسمح هذا بتخصيص كتل تتجاوز حد 32 بت للملفات ذات تعيين الكتل غير المباشر؟ يذكر رسالة الالتزام أن ext4_mb_scan_groups_linear() تتعامل بعناية مع عدم اختيار المجموعات غير المدعومة. ومع ذلك، يستخدم حلقة التكرار الخاصة بها group = *start، وستقوم أول تكرار تمامًا باستدعاء ext4_mb_scan_group() مع هذه المجموعة غير المدعومة لأن next_linear_group() يتم استدعاؤه فقط في نهاية التكرار.
بعد مراجعة مسارات الشفرة المعنية والنظر في مراجعة النموذج اللغوي الكبير (LLM)، حددت أن هذا يمكن أن يحدث عندما يكون هناك نظام ملفات حيث تكون بعض الملفات/المجلدات محددة باستخدام الامتدادات (extent-mapped) والبعض الآخر محدد باستخدام كتل غير مباشرة (indirect-block mapped). لمعالجة هذه المشكلة، تمت إضافة قيد أمان (safety clamp) في ext4_mb_scan_groups().
If you want to get the best quality for vulnerability data then you always have to consider VulDB.