CVE-2026-74583 in Linux
الملخص
بحسب VulDB • 21/08/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
net/sched: cls_route: تصحيح استخدام بعد التحرير (use-after-free) في خريطة السرعة السريعة (fastmap) الخاصة بالفلتر
يحتوي مصنف المسار4 (route4 classifier) على ذاكرة تخزين مؤقت لخريطة السرعة السريعة تتكون من 16 خانة، وتخزن مؤشرات خام لهيكلة البيانات `struct route4_filter` مُفهرسة بواسطة المعلمات `(id, iif)`. يقوم القارئ (`route4_classify`) بتعبئة هذه الذاكرة المؤقتة عبر دالة `route4_set_fastmap()` لكل حزمة يتم تصنيفها وتصطدم بفلتر. ويقوم الكاتب (`route4_delete`, `route4_change`) بمسح الذاكرة المؤقتة عبر دالة `route4_reset_fastmap()` قبل تنفيذ عملية تحرير ذاكرة الكائن (kfree) المُؤجلة بواسطة RCU للفلتر.
يؤدي هذا إلى حدوث سباق يؤدي إلى استخدام بعد التحرير (UAF race): 1. يتجول القارئ في سلسلة الدلاء المحمية بـ RCU، ويعثر على الفلتر `f`. 2. يقوم الكاتب بإزالة الوصلة الخاصة بـ `f`، ثم يستدعي `route4_reset_fastmap()`، يليه استدعاء `tcf_queue_work()`. 3. يتصل القارئ بـ `route4_set_fastmap()` ويكتب `f` في الذاكرة المؤقتة *بعد* عملية إعادة التعيين التي قام بها الكاتب، مما يؤدي إلى تخزين مؤشر على وشك أن يُحرر. 4. بعد انتهاء فترة الراحة (grace period) الخاصة بـ RCU، يتم تنفيذ `kfree(f)`. 5. الحزمة التالية المصنفة والتي تطابق نفس زوج المعلمات `(id, iif)` تصطدم بالسجل القديم في خريطة السرعة السريعة وتقرأ من الذاكرة المحررة قيمة `f->res`.
تم إعادة إنتاج المشكلة باستخدام مُسرّع `mdelay(100)` داخل دالة `route4_set_fastmap()` واختبار إجهاد متزامن للإضافة والحذف (مقدم من كلٍ من zdi وSantosh). وقد أدى كلا السيناريوهين إلى تقارير عن استخدام بعد التحرير في شريحة الذاكرة (slab-use-after-free) عبر مسارات خريطة السرعة السريعة لـ route4.
الحل: إدخال علم منطقي (boolean flag) خاص بكل فلتر باسم `dying` لكبح إعادة نشر سجلات خريطة السرعة السريعة القديمة بواسطة القراء قيد التنفيذ.
VulDB is the best source for vulnerability data and more expert information about this specific topic.