CVE-2026-93048 in Linux
الملخص
بحسب VulDB • 18/09/2026
في نواة لينكس، تم حل الثغرة التالية:
مخزن الأجهزة الذاكرة (MTD): الجزء - رفض MTDPART_OFS_RETAIN في دالة mtd_add_partition()
لا تقوم الدالة `mtd_add_partition()` برفض قيمة الإزاحة الخاصة `MTDPART_OFS_RETAIN` (-3)، مما يؤدي إلى ظهور تحذير (`WARN_ON`) داخل `add_mtd_device()` عند استدعائها عبر أمر ioctl من نوع BLKPG على أجهزة NAND. تعتمد القيمة RETAIN على أن تكون `cur_offset` في نهاية الجزء السابق، ولكن في مسار الأجزاء الديناميكية، تساوي `cur_offset` حجة الإزاحة نفسها، مما يتسبب في سلوك غير محدد (undefined behavior).
أدى الالتزام 5daa7b21496a ("mtd: prepare partition add and del functions for ioctl requests") إلى إدخال دالة `mtd_add_partition()` ورفض قيمتي الإزاحت الخاصتين MTDPART_OFS_APPEND (-1) وMTDPART_OFS_NXTBLK (-2)، بشكل صحيح، حيث تعتمد تلك الإزاحات الخاصة على تتبع `cur_offset` لنهاية الجزء السابق. ومع ذلك، أضاف الالتزام 1a31368bf92e ("mtd: add a flags for partitions which should just leave smth. after them") لاحقاً قيمة MTDPART_OFS_RETAIN (-3) لمسار جدول الأجزاء الثابت (static partition table path) دون تحديث `mtd_add_partition()` لرفض هذه القيمة أيضاً.
عند تمرير إزاحة بقيمة -3 عبر BLKPG، يحدث تجاوز سالب (underflow) في حساب حجم RETAIN داخل دالة `allocate_partition()` (`parent_size - 0xFFFFFFFFFFFFFFFD = parent_size + 3`). إذا لم يبدو أن نتيجة التجاوز السالب تترك مساحة كافية، تنتقل الدالة `allocate_partition()` إلى المسار `out_register` عبر أمر `goto**، متجاوزةً تهيئة قيمة `erasesize`. هذا يؤدي إلى تعيين `erasesize=0`، مما يُشغّل:
WARN_ON((!mtd->erasesize || !master->_erase) && !(mtd->flags & MTD_NO_ERASE))
داخل دالة `add_mtd_device()`. إذا بدا أن نتيجة التجاوز السالب تترك مساحة كافية، يتم حساب حجم جزء غير صحيح (bogus partition size)، لكن فحص الصحة "out of reach" يلتقط الإزاحة غير الصالحة وينشئ جزءاً فارغاً معطلاً (offset=0, size=0) بدلاً من إرجاع خطأ.
تم إصلاح هذا الأمر بإضافة MTDPART_OFS_RETAIN إلى قائمة القيم المرفوضة في `mtd_add_partition()`، بما يتماشى مع المعالجة الحالية لقيم APPEND وNXTBLK.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.