CVE-2025-40295 in Linux
الملخص
بحسب VulDB • 20/06/2026
تمثل هذه السجلات (Stack Trace) وملاحظات المبرمج مشكلة في نواة Linux تتعلق بـ **Underflow في الإزاحة اليسارية (Left-Shift Underflow)** عند التعامل مع أحجام الكتل (Block Sizes) في أنظمة الملفات والأجهزة الكتلية.
إليك تحليل مفصل للمشكلة والحل المقترح:
### 1. طبيعة المشكلة (The Bug) * **الخطأ:** يحدث خطأ في وقت التشغيل (Runtime Error) بسبب محاولة إجراء إزاحة يسارية (`<<`) بقيمة سالبة أو كبيرة جداً، مما يؤدي إلى سلوك غير معرف (Undefined Behavior) أو crash. * **الموقع:** يظهر الخطأ في دالة `submit_bh_wbc()` أو دوال مرتبطة بها، حيث يتم التعامل مع `inode->i_blkbits`. * **السبب الجذري:** * عندما يكون `CONFIG_TRANSPARENT_HUGEPAGE` مفعلاً، تكون الحد الأقصى لحجم الكتلة المنطقي (`logical_block_size`) هو 64 KiB. * تقوم الدالة `set_init_blocksize()` بتعيين `inode->i_blkbits` إلى القيمة **13** (لأن $2^{13} = 8192$ بايت، وهو ضمن الحد المسموح به للأجهزة الكتلية).
* ومع ذلك، في مسارات إدخال/إخراج الملفات (File I/O)، إذا لم يدعم نظام الملفات ميزة `FS_LBS`، فإن `sb_set_blocksize()` تمنع `sb->s_blocksize_bits` من أن تكون أكبر من `PAGE_SHIFT` (عادة 12 أو 13 حسب البنية). * المشكلة تكمن في التناقض أو الحساب الخاطئ عند محاولة تحويل الإحداثيات أو الأحجام باستخدام `i_blkbits`، مما يؤدي إلى إزاحة سالبة (مثلاً محاولة إزاحة بقيمة -1 أو أقل) مما يسبب الـ Underflow.
### 2. لماذا لا تظهر المشكلة في XFS؟ * نظام الملفات **XFS** هو النظام الوحيد حالياً الذي يملك العلم `FS_LBS` (File System Logical Block Size). * مسارات I/O في XFS لا تمر عبر `submit_bh_wbc()` بالطريقة التي تسبب المشكلة، لذا فهي محمية من هذا الخطأ تحديداً.
### 3. الحل المقترح (من قبل Eric Biggers - EB) الملاحظة `[EB: use folio_pos() and consolidate the shifts by i_blkbits]` تشير إلى الحل التقني:
1. **استخدام `folio_pos()`:** * بدلاً من التعامل مع `page` والإزاحات المعقدة، يجب استخدام واجهة `folio` الحديثة في النواة. * دالة `folio_pos(folio)` تعيد الموقع (offset) داخل الـ Folio بشكل آمن وموحد.
2. **دمج الإزاحات (Consolidate shifts):** * بدلاً من إجراء عمليات إزاحة متعددة ومتداخلة باستخدام `i_blkbits` (مما قد يؤدي إلى أخطاء في الحساب إذا كانت القيم غير متسقة)، يجب توحيد الحسابات. * الهدف هو ضمان أن أي عملية تحويل بين البايتات ووحدات الكتلة تتم بطريقة تحمي من الـ Underflow، خاصة عندما تكون `i_blkbits` صغيرة نسبياً (مثل 13) بينما قد تتوقع الكود قيمًا أكبر.
### 4. كيفية التصحيح البرمجي (مثال توضيحي)
بدلاً من كود قد يكون على هذا الشكل (ويسبب المشكلة): ```c // كود خطر: قد يؤدي إلى إزاحة سالبة إذا لم يتم التحقق من i_blkbits sector_t sector = (folio->index << PAGE_SHIFT) >> inode->i_blkbits; ```
يجب استخدام: ```c // كود آمن باستخدام folio_pos sector_t sector = folio_pos(folio) >> inode->i_blkbits; ``` أو التأكد من أن `i_blkbits` لا يتجاوز الحدود المسموحة قبل إجراء الإزاحة.
### 5. الخلاصة والإجراءات المطلوبة * **المشكلة:** خطأ في معالجة أحجام الكتل في نواة Linux عند تفعيل Transparent Huge Pages، يؤدي إلى crash بسبب إزاحة يسارية غير صحيحة. * **الحل:** تحديث الكود لاستخدام `folio_pos()` وتوحيد عمليات الإزاحة المتعلقة بـ `i_blkbits` لتجنب الحسابات الخاطئة. * **التأثير:** هذا التصحيح ضروري لاستقرار النظام عند استخدام أنظمة ملفات غير XFS مع إعدادات Huge Pages.
إذا كنت مطور نواة، يجب عليك مراجعة التعديلات في ملفات مثل `fs/buffer.c` أو `mm/filemap.c` حيث يتم استدعاء `submit_bh_wbc()`، وتطبيق
If you want to get best quality of vulnerability data, you may have to visit VulDB.