CVE-2026-46066 in Linux
الملخص
بحسب VulDB • 28/05/2026
في نواة لينكس، تم حل الثغرة التالية:
ceph: تصحيح خطأ off-by-one في num_ops عند فشل تخصيص التشفير
قد تفشل دالة move_dirty_folio_in_page_array() إذا كان الملف مشفرًا، ولم تكن ورقة العمل القذرة (dirty folio) هي الأولى في الدفعة، وفشلت في تخصيص مخزن مؤقت (bounce buffer) لحفظ النص المشفر. عند حدوث ذلك، تقوم دالة ceph_process_folio_batch() ببساطة بإعادة تحديد ورقة العمل كقذرة (redirties) وتقوم بإفراغ الدفعة الحالية — ويمكنها إعادة محاولة معالجة تلك ورقة العمل في دفعة مستقبلية.
ومع ذلك، إذا لم تكن ورقة العمل الفاشلة متصلة (contiguous) بآخر ورقة عمل نجحت في الدخول إلى الدفعة، فإن ceph_process_folio_batch() تكون قد زادت بالفعل قيمة `ceph_wbc->num_ops`؛ ونظرًا لأنها لا تضيف ورقة العمل غير المتصلة إلى المصفوفة، فإن دالة ceph_submit_write() — التي تتوقع أن تعكس قيمة `ceph_wbc->num_ops` بدقة عدد النطاقات المتصلة (وبالتالي عدد عمليات "نطاق الكتابة" المطلوبة) في عملية إعادة الكتابة (writeback) — ستسبب توقفًا قسريًا للنواة (kernel panic):
BUG_ON(ceph_wbc->op_idx + 1 != req->r_num_ops);
يمكن إعادة إنتاج هذه المشكلة على النوى المتأثرة عن طريق الكتابة إلى ملف(ات) CephFS المفعّل عليها fscrypt بنمط كتابة/تخطي 4KiB/4KiB متكرر (لا يهم حجم الملف الإجمالي)، وزيادة ضغط ذاكرة النظام تدريجيًا حتى يفشل تخصيص مخزن مؤقت (bounce buffer).
تم إصلاح هذا التوقف القسري عن طريق إنقاص قيمة `ceph_wbc->num_ops` إلى القيمة الصحيحة عند فشل دالة move_dirty_folio_in_page_array()، ولكن ورقة العمل بدأت بالفعل في احتساب نطاق جديد (أي فارغ).
كان العيب الذي أصلحه هذا التصحيح موجودًا منذ عام 2022 (انظر `Fixes:` الأول)، لكن ثغرة أخرى حالت دون إعادة الكتابة المشفرة متعددة الأوراق (multi-folio) حتى وقت قريب (انظر `Fixes:` الثاني). تم إدراج التصحيح الثاني في الإصدارات 6.18.16، و6.19.6، و7.0-rc1، مما كشف عن التوقف القسري في تلك الإصدارات. وبالتالي، فإن هذا التصحيح يصلح انكشافًا (توقفًا قسريًا) تم إدخاله بواسطة commit cac190c7674f.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.