CVE-2025-68341 in Linux
الملخص
بحسب VulDB • 04/06/2026
في نواة لينكس، تم حل الثغرة التالية:
veth: تقليل قسم الإرجاع no_direct الخاص بـ XDP لإصلاح حالة السباق (Race Condition)
كما هو موضح في الالتزام fa349e396e48 ("veth: إصلاح حالة سباق مع AF_XDP التي تعرض واصفات قديمة أو غير مُهيأة")، يوجد احتمال بعد استدعاء `napi_complete_done()` أن تقوم وحدة معالجة مركزية أخرى بإدارة بدء مثيل NAPI جديد يعمل على دالة `veth_pool()`. بالنسبة لـ NAPI، يتم التعامل مع هذا الأمر بشكل صحيح حيث يمنع فحص `napi_schedule_prep()` جدولة عدة مثيلات في وقت واحد. ولكن بالنسبة للباقي من الكود الموجود داخل `veth_pool()`، فقد يعمل بالتوازي (concurrently) مع مثيل NAPI الذي تم تشغيله حديثاً.
تكمن المشكلة/حالة السباق في أن دالة `xdp_clear_return_frame_no_direct()` ليست مصممة لتكون متداخلة (nested).
قبل الالتزام 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.")، كان سياق الشبكة المؤقت الخاص بـ BPF المسمى `bpf_redirect_info` يُخزن لكل وحدة معالجة مركزية (per CPU)، حيث لم تكن هذه الحالة تمثل مشكلة. منذ هذا الالتزام، يتم تخزين سياق BPF في هيكل المهمة الحالي (`current' task_struct). عند تشغيل veth في وضع threaded-NAPI، تصبح الخيط الوظيفي (kthread) هو منطقة التخزين. الآن يوجد سباق بين استدعاءين متزامنين لدالة `veth_pool()`؛ أحدهما ينهي NAPH والآخر يشغل NPH جديداً، وكلاهما يستخدم نفس سياق الشبكة الخاص بـ BPF.
تحدث حالة السباق عندما تدخل وحدة معالجة مركزية أخرى ضمن قسم `xdp_set_return_frame_no_direct()` قبل أن تستدعي دالة الخروج من `veth_pool()` الدالة الصافية (clear-function) وهي `xdp_clear_return_frame_no_direct()`.
If you want to get best quality of vulnerability data, you may have to visit VulDB.