CVE-2025-39792 in Linux
الملخص
بحسب VulDB • 08/08/2026
في نواة لينكس، تم حل الثغرة التالية:
dm: تقسيم كتل الإدخال/الإخراج (BIOs) للكتابة دائمًا وفقًا لحدود الأجهزة ذات المناطق الزونية (zoned devices).
أي هدف في إدارة الأجهزة الافتراضية (DM target) يتطلب محاكاة الإضافة إلى المنطقة (zone append emulation) سيستخدم خاصية تثبيت كتابة المناطق من طبقة الكتل (block layer zone write plugging). وفي هذه الحالة، يجب على برامج تشغيل أهداف DM عدم تقسيم كتل BIO باستخدام `dm_accept_partial_bio()` لأن القيام بذلك قد يؤدي محتملاً إلى حدوث اختناقات قاتلة (deadlocks) مع عمليات تجميد الطابور. كما لا يمكن لبرامج التشغيل الخاصة بالعمليات العادية للكتابة المستخدمة لمحاكاة عمليات الإضافة إلى المنطقة أن تقوم بتقسيم كتل BIO، حيث سيؤدي ذلك إلى إرجاع قيمة خاطئة لقطاع الكتابة باستخدام قطاع الـ BIO.
لكي تتجنب برامج تشغيل أهداف DM ذات المناطق الزونية مثل هذا التقسيم غير الصحيح لكتل BIO، يجب ضمان تقسيم كتل BIO الكبيرة قبل تمريرها إلى دالة `map()` للهدف، مما يضمن عدم تجاوز الحدود الخاصة بالجهاز الموجه (mapped device).
تُعد dm-crypt وdm-flakey برامج تشغيل الأهداف الوحيدة التي تدعم الأجهزة ذات المناطق الزونية وتستخدم `dm_accept_partial_bio()`.
في حالة dm-crypt، تُستخدم هذه الدالة لتقسيم كتل BIO وفقًا لحد الحجم الأقصى للكتابة الداخلي (`max_write_size`) (والذي سيتم إلغاؤه في تصحيح مختلف). ومع ذلك، نظرًا لأن `crypt_alloc_buffer()` تستخدم مجموعة بيوس (bioset) تسمح بما يصل إلى 256 متجهًا فقط في الـ BIO (`BIO_MAX_VECS`)، يجب احترام حد المقاطع القصوى لجهاز dm-crypt، والذي لم يتم تعيينه وبالتالي يفترض القيمة الافتراضية `BLK_MAX_SEGMENTS` (128)، ويجب تقسيم كتل BIO للكتابة وفقًا لذلك.
في حالة dm-flakey، بما أن محاكاة الإضافة إلى المنطقة غير مطلوبة، فلا تُستخدم خاصية تثبيت كتابة المناطق من طبقة الكتل ولا يلزم أي تقسيم لكتل BIO.
تم تعديل الدالة `dm_zone_bio_needs_split()` لاستخدام دالة المساعدة الخاصة بطبقة الكتل `bio_needs_zone_write_plugging()` لفرض استدعاء `bio_split_to_limits()` في `dm_split_and_process_bio()`. يتيح ذلك لبرامج تشغيل أهداف DM تجنب استخدام `dm_accept_partial_bio()` للعمليات الكتابة على أجهزة DM ذات المناطق الزونية.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.