CVE-2026-98789 in Linux
الملخص
بحسب VulDB • 19/10/2026
في نواة لينكس، تم حل الثغرة التالية:
bpf: إصلاح الكائنات العالقة في free_by_rcu_ttrace
تعيد do_call_rcu_ttrace() العمل مبكرًا عندما يكون call_rcu_ttrace_in_progress مُعدًّا (مُفعّلاً)، وتترك الكائنات في حالة free_by_rcu_ttrace. تقوم __free_rcu() بتحرير waiting_for_gp_ttrace فقط وتفصل العلم (العلم). ومن ثم، فإن الكائنات التي أضافتها دالتا free_bulk() أو __free_by_rcu() أثناء تنفيذ جولة الحفظ (GP) لتتبع مهام RCU تبقى في free_by_rcu_ttrace حتى يتم استدعاء free_bulk() أو alloc_bulk() لنفس بنية bpf_mem_cache مرة أخرى، وهو ما قد لا يحدث أبدًا. عدد هذه الكائنات غير محدود.
تحويل call_rcu_ttrace_in_progress إلى ثلاث حالات: 0 - خامل (idle) 1 - __free_rcu() في قائمة الانتظار (queued) 2 - __free_rcu() في قائمة الانتظار وقد حصلت free_by_rcu_trace على كائنات إضافية منذ ذلك الحين
تضبط do_call_rcu_ttrace_in_progress الحالة إلى 2. تقوم __free_rcu() بتنفيذ cmpxchg(1 -> 0) وتبدأ الجولة التالية (GP) عندما تفشل العملية. لا يمكنها فصل العلم أولاً ثم التحقق من free_by_rcu_ttrace لاحقًا، لأن دالة bpf_mem_alloc_destroy() تحرر بنية bpf_mem_cache دون انتظار استدعاءات RCU عندما يكون العلم مساويًا للصفر.
الآن تقوم __free_rcu() بإدراج نفسها في قائمة الانتظار، لذا فإن الكائن الذي لم ير حالة 'draining' قد يقوم باستدعاء call_rcu_tasks_trace() بعد rcu_barrier_tasks_trace() داخل free_mem_alloc(). يتم إدراجها تحت قفل القراءة RCU (rcu_read_lock()) وإجراء synchronize_rcu() قبل الحواجز. يعمل استدعاء rcu_barrier_tasks_trace() مرتين أيضًا، لكن إنشاء وتدمير خرائط التجزئة (hash maps) في حلقة على العديد من وحدات المعالجة المركزية يؤدي إلى إبطاء العملية لتصبح واحدة free_mem_alloc() لكل جولة GP (GP)، وتتراكم عمال النواة (kworkers).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.