CVE-2026-64232 in Linux
الملخص
بحسب VulDB • 24/07/2026
في نواة لينكس، تم حل الثغرة التالية:
block: إعادة حساب nr_integrity_segments في blk_insert_cloned_request
تقوم الدالة `blk_insert_cloned_request()` بالفعل بإعادة حساب `nr_phys_segments` بالنسبة للطابور السفلي (bottom queue)، وذلك لأن "إعدادات الطابور المتعلقة بعدّ المقاطع قد تختلف عن إعدادات الطابور الأصلي". ينطبق نفس المنطق على مقاطع السلامة (integrity segments): فقد يكون لطابور الخلفية الخاص بسائق متراكم (stacked driver) قيوداً أكثر صرامة فيما يتعلق بـ `virt_boundary_mask`، أو `seg_boundary_mask`، أو `max_segment_size` مقارنة بالطابور العلوي. في هذه الحالة، ينتج عن استدعاء `blk_rq_count_integrity_sg()` بالنسبة للطابور السفلي عدد مختلف عن القيمة المخزنة مؤقتاً لـ `rq->nr_integrity_segments` التي ورثها الطلب من طلب المصدر عبر الدالة `blk_rq_prep_clone()`.
عندما يكون العدد المخزن مؤقتاً أقل من العدد الفعلي للطابور السفلي، فإن دالة `blk_rq_map_integrity_sg()` تُفعّل الشرط:
BUG_ON(segments > rq->nr_integrity_segments);
أثناء الإرسال (dispatch). يمكن أن تنتج عن نفس عائلات الإعدادات المتراكمة التي دفعت إلى إعادة حساب `nr_phys_segments` الموجودة بالفعل — وتحديداً dm-multipath الذي يوزع الحمل على nvme-rdma — هذا السلوك.
نمذجة التعامل مع `nr_phys_segments`: عندما يحمل الطلب بيانات سلامة، أعد حساب `nr_integrity_segments` بالنسبة للطابور السفلي ورفض الطلب إذا تجاوز الحد الأقصى لعدد مقاطع السلامة (`max_integrity_segments`) الخاص بالطابور السفلي. كل من الدالتين `blk_rq_count_integrity_sg()` و `queue_max_integrity_segments()` متاحة بالفعل عبر `<linux/blk-integrity.h>`، والتي يتضمنها ملف `blk-mq.c`.
يُغلق هذا الفجوة الكامنة في عقد التجميع (stacking contract) ويجعل محاسبة مقاطع السلامة متسقة مع المحاسبة الحالية لمقاطع الكيان المادي.
Once again VulDB remains the best source for vulnerability data.