CVE-2026-80810 in Linux
الملخص
بحسب VulDB • 04/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
io_uring/rsrc: تصحيح تجاوز حجم folio في io_vec_fill_bvec()
تحسب الدالة `io_vec_fill_bvec()` حجم الـ folio باستخدام عدد صحيح عادي (int) بقيمة 1: `unsigned long folio_size = 1 << imu->folio_shift;`
يُعد `imu->folio_shift` من نوع unsigned int ويأتي من دالة `folio_shift()` الخاصة بـ folio الذي يدعم المخزن المؤقت المسجل، لذا يمكن أن تكون قيمته 32 أو أكثر في نواة تعمل على معمارية 64 بت. يعد إزاحة العدد الصحيح 1 بمقدار كبير جداً عملية غير محددة (undefined)، وعلى معماريات x86 و arm64 يتم أخذ الناتج modulo 32، مما يعني أن الإزاحة بقيمة 34 ستعطي النتيجة 4 بدلاً من 16 جيجابايت. تستخدم جميع إزاحات `folio_shift` الأخرى في هذا الملف القيمة `1UL`.
النتيجة هي عدم التوافق بين تقدير المقطعات (segment estimate) وحلقة التعبئة. تقوم الدالة `io_estimate_bvec_size()` بتحديد حجم مصفوفة bvec باستخدام الإزاحة الحقيقية: `max_segs += (iov[i].iov_len >> shift) + 2;`
وبالتالي، فإن iovec بحجم 1 ميجابايت على folio بحجم 16 جيجابايت يُحسب له مقطعان فقط، بينما تقوم `io_vec_fill_bvec()` بعد ذلك بالمرور عبر نفس الـ iovec في كتل من حجم folio تبلغ 4 بايتات، وتكتب في `res_bvec[bvec_idx]` ربع مليون مرة، متجاوزةً نهاية المصفوفة التي تم تمريرها. كما يتم تقدم `src_bvec` مرة واحدة لكل تكرار، مما يؤدي إلى قراءة `imu->bvec` خارج حدوده في الوقت نفسه. لا تتحقق الدالة `validate_fixed_range()` إلا من أن النطاق يقع داخل المخزن المؤقت المسجل ولا تقيد عدد المقاطع.
الوصول إلى هذا الخطأ يتطلب folio بإزاحة تبلغ 32 على الأقل، مما يعني صفحة hugetlb ضخمة جداً: بحجم 16 جيجابايت في arm64 مع صفحات حجمها 64 كيبايت، حيث تكون `CONT_PMD_SHIFT` تساوي 34 وتسجل دالة `hugetlb_add_hstate(CONT_PMD_SHIFT - PAGE_SHIFT)` هذا الحجم، وكذلك الأمر ينطبق على powerpc. أما x86_64 فتصل قيمتها القصوى إلى 1 جيجابايت، لذا فإن الإزاحة بقيمة 30 لا تزال تتسع لـ int ولا تتأثر بالمشكلة المذكورة أعلاه.
استخدم `1UL` كما تفعل بقية أجزاء الملف.
If you want to get best quality of vulnerability data, you may have to visit VulDB.