CVE-2026-98974 in Linux
الملخص
بحسب VulDB • 23/10/2026
في نواة Linux، تم إصلاح الثغرة التالية:
xfs: تصحيح تبادل أحجام الملفات في عملية exchange-range-to-eof
نشر Norbert Szetei التصحيح (patch) الذي يحتوي على وصف غير مكتمل لخلل في علم XFS_IOC_EXCHANGE_RANGE TO_EOF. يخدع هذا الخلل دالة exchange-range لتعديل ملف بحيث يحتوي على كتل مشتركة تبدأ بعد نهاية الملف (EOF)، وهو أمر لا يُسمح به أبداً لأن الملفات لا تحتوي على بيانات مكتوبة تتجاوز EOF، ولا يمكن مشاركة سوى كتل البيانات المكتوبة. وهذا الأمر جوهري لجميع السلوكيات غير الصحيحة التي تليه.
في النهاية، حصلتُ من Norbert على وصف لما يحدث بشكل خاطئ:
> حسناً. إليك التفاصيل مع أرقام الكتل الفيزيائية (physical block numbers)، بكتلات حجمها 4 كيلوبايت. peer هو الملف الذي يتم إعادة كتابته، و file1 هو الملف الذي ينتهي به الأمر بإزالة العلم (flag) الخاص به. > > البداية: لا توجد كتل مشتركة: > > حجم peer = 4096 -> [100]
> حجم file1 = 12288 -> [200] [201] [202]
> حجم donor1 = 4096 -> [300]
> حجم donor2 = 4096 -> [400]
> > 1. FICLONERANGE: نسخ كتلة peer إلى الفتحة الوسطى لـ file1: > > حجم peer = 4096 -> [100]
> حجم file1 = 12288 -> [200] [100] [202] تم تعيين علم reflink
> ^^^^^ كلا الملفين يملكان الكتلة 100 > > 2. XFS_IOC_EXCHANGE_RANGE: تبادل file1 مع donor1، حيث file1_offset = 0, file2_offset = 8192, length = 0, TO_EOF. يتم تبادل كتلة واحدة، ويتم تبديل الأحجام معها: > > حجم file1 = 4096 -> [200] [100] [300] تم تعيين علم reflink
> ^^^^^^^^^^^ لا تزال مملوكة، لكنها الآن تتجاوز الحجم (past the size) > حجم donor1 = 12288 -> [202]
> > file1 يقول إن طوله كتلة واحدة بينما هو يملك ثلاثاً منها. لم يتم إلغاء تعيين أي شيء (unmapped). ملف2_offset هي الكتلة 2، لذا لا يمكن لهذا التبادل أن يحذف العلم. > > 3. XFS_IOC_EXCHANGE_RANGE: تبادل file1 مع donor2، حيث كلا الإزاحتين offsets = 0، والطول length = 4096. بناءً على i_disk_size، هذا يمثل ملفاً مكوناً من كتلة واحدة يتبادل كل شيء مع آخر مماثل، لذا فإن xmi_can_exchange_reflink_flags() توافق ويتم حذف العلم: > > حجم file1 = 4096 -> [400] [100] [300] تم حذف علم reflink
> حجم donor2 = 4096 -> [200]
> > الكتلة 100 لا تزال مشتركة مع peer. > > 4. pwrite(file1, 4096, 4096)، وهي الفتحة الثانية لـ file1، والكتلة 100. بما أن xfs_is_cow_inode(file1) خاطئة (false)، فلا يوجد نسخ عند الكتابة (CoW): > > حجم peer = 4096 -> [100] نفس الكتلة، بمحتويات جديدة
> > الكتلة 100 هي الوحيدة ذات الأهمية هنا. نموذج الاستغلال (PoC) أدناه يقرأ ملفاً يُسمى peer في الدليل الحالي. تحتاج نظام الملفات إلى دعم reflink و exchange-range، وهو ما يتم تفعيله افتراضياً بواسطة mkfs.xfs الإصدار 7.x.
لذا نعم، TO_EOF يسبب خللاً في حجم الملف حتى لو كان يتبادل كتلة البيانات بشكل صحيح. فيما يلي السلوك المقصود لـ XFS_EXCHANGE_RANGE_TO_EOF كما هو موضح في صفحة الدليل (manpage):
"تجاهل معلمة الطول. يتم نقل جميع البايتات في file1_fd من ملف1_offset إلى نهاية الملف (EOF) إلى file2_fd، ويتم تعيين حجم ملف2 ليكون (file2_offset + (file1_length - file1_offset)). وفي الوقت نفسه، يتم نقل جميع البايتات في ملف2 من file2_offset إلى EOF إلى ملف1، ويتم تعيين حجم ملف1 ليكون (file1_offset + (file2_length - file2_offset))."
بعبارة أخرى، إذا قمنا بتبادل جزء فقط من بيانات الملف، فيجب علينا تبادل الجزء المقابل لحجم الملف المتعلق بالبيانات المتبادلة. وللأسف، يقوم الكود بقلب أحجام الملفات على القرص (ondisk) وأحجامها الموجودة في الذاكرة (incore)، وهو أمر غير صحيح إذا مرر المتصل إزاحةً (offset) لا تساوي صفراً.
وبسبب الخلط الناتج عن أحجام الملفات، يستخدم نموذج الاستغلال (PoC) استدعاءً ثانياً لـ exchange-range على ملف يبدو أنه مفرد وغير مربوط بـ reflink. وبما أن حجم الملف تم تعيينه بشكل غير صحيح، فإن exchange-range تعتقد أنها تتبادل المحتويات الكاملة لملفين وتقوم بحذف علم reflink من الملف المعطوب. وهذا يتيح كتابة موسعة للملف المعطوب لإعادة كتابة الكتلة المشتركة التي تقع مباشرة بعد EOF. وقد أصبح هذا معروفاً عامياً باسم refluxfs.
بمجرد تعيين أحجام الملفات بشكل صحيح، لن يعتقد استدعاء exchange-range الثاني أنه يقوم بتبادل كامل المحتويات، لذا فلن يحذف علم reflink من أيٍّ من حجي الملفين (file arguments).
تابع Norbert إعلانه عن الإصدار السابق من هذا التصحيح بشكوى ثانية حول عدم تعاملنا بشكل صحيح مع حالة i_disk_size:
> يتم تحديد حدود الإزاحات بناءً على الحجم الموجود في الذاكرة (incore i_size) ولكنها تُطرح من > ---مقتطف---
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.