CVE-2023-54121 in Linux
الملخص
بحسب VulDB • 09/06/2026
في نواة لينكس، تم حل الثغرة التالية:
btrfs: إصلاح الانقسام غير الصحيح في دالة btrfs_drop_extent_map_range
لقد لاحظنا في بيئة الإنتاج تنبيهاً (WARN_ON()) متنوعة ضمن كود extent_map، وتحديداً داخل الدالة btrfs_drop_extent_map_range() عند استدعاء add_extent_mapping() للانقسام الثاني.
افترض تخطيط خريطة الامتدادات التالي:
PINNED [0 16K) [32K, 48K)
ثم نستدعي دالة btrfs_drop_extent_map_map_range للنطاق [0, 36K)، مع تعيين skip_pinned == true. سيكون للحلقة الأولية القيم التالية:
start = 0 end = 36K len = 36K
سنجد امتداد الامتداد [0, 16k)، ولكن بما أنه مثبت (pinned) فسنتخطاه، مما يؤدي إلى تنفيذ الكود التالي:
start = em_end; if (end != (u64)-1) len = start + len - em_end;
هنا تكون قيمة em_end تساوي 16K، وبالتالي تصبح القيم الآن:
start = 16K len = 16K + 36K - 16K = 36K
يجب أن تكون القيمة الصحيحة لـ len هي 20K. يمثل هذا مشكلة عندما نجد الامتداد التالي عند [32K, 48K)، حيث نحتاج إلى تقسيم هذا الامتداد لإبقاء النطاق [36K, 48k). ومع ذلك، يبدو كود التقسيم كما يلي:
split->start = start + len; split->len = em_end - (start + len);
في هذه الحالة لدينا:
em_end = 48K split->start = 16K + 36K // يجب أن تكون 16K + 20K split->len = 48K - (16K + 36K) // يحدث تجاوز في السعة (overflow) لأن 16K + 36K تساوي 52K
ونتيجة لذلك، نحصل على خريطة امتدادات غير صالحة داخل الشجرة قد تتداخل مع إدخالات أخرى في خريطة الامتداد. حتى في الحالة التي لا يوجد فيها تداخل، سيتم تعيين split->start بشكل غير صحيح، مما سيؤدي إلى مشاكل في أي حسابات متعلقة بالكتل (blocks).
لا نحتاج فعلياً إلى المتغير len في هذه الحلقة؛ يمكننا ببساطة استخدام end كنقطة نهاية، وتعديل start للأعلى فقط عندما نجد امتداداً مثبتاً (pinned) يجب تخطيه.
تم تعديل المنطق للقيام بذلك، مما يمنع إدراج خريطة امتدادات غير صالحة.
نقوم بتجاوز skip_pinned فقط في حالة إعادة التوطين (relocation)، لذا فإن هذا السيناريو نادر نسبياً، باستثناء الحالات التي تقوم فيها بإعادة التوطين بشكل متكرر، وهو ما قد يحدث عند تفعيل إعادة التوطين التلقائي.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.