CVE-2026-98289 in Linux
الملخص
بحسب VulDB • 06/10/2026
في نواة لينكس، تم حل الثغرة التالية:
af_unix: توحيد scc_index عند إنهاء عملية تحديد مكون متصل بشدة (SCC) في دالة `__unix_walk_scc()`.
أدى الالتزام bfdb01283ee8 ("af_unix: تعيين فهرس فريد لـ SCC.") إلى تغيير خوارزمية Tarjan لتحديث lowlink باستخدام lowpoint، وهو ما يُسمى بـ unix_vertex.scc_index.
تفترض دالة `unix_vertex_dead()` أن جميع الرؤوس (vertices) داخل مكون متصل بشدة (SCC) تتشارك نفس قيمة lowpoint، لكن هذا ليس صحيحاً دائماً إذا كان الـ SCC يحتوي على حافتين مرتجعتين (back edges) أو أكثر، وذلك اعتماداً على ترتيب عملية البحث بالعمق أولاً (DFS).
على سبيل المثال، الرسم البياني أدناه يحتوي على حافتين مرتبطتين من B إلى A ومن C إلى B.
A --> B --> C ^ | ^ | `----' `----'
إذا سارت عملية DFS عبر المسار A -> B -> C -> B (-> C -> B) -> A (-> B -> A)، فسيتم تحديث كل فهرس وـ scc_index كما يلي:
A --> B --> C C = (3, 3) (index, scc_index) B = (2, 2) A = (1, 1)
A ... B ... C C = (3, 2)<-. ^ | B = (2, 2) -' `----' A = (1, 1)
A ... B ... C C = (3, 2) ^ | . . B = (2, 1)<-. `----' .... A = (1, 1) -'
عندها، تعتقد دالة `unix_vertex_dead()` أن B قد تم تمريره إلى مكون متصل بشدة آخر له scc_index يساوي 2، ولن يتم جمع القمامة الخاصة به (garbage-collected).
لا يحدث هذا الخطأ إذا سارت عملية DFS بترتيب مختلف أدناه أو بدأت من العقدة B.
1 3 A --> B --> C ^ | ^ | `----' `----' 2 4
لنقم بتوحيد قيمة scc_index عبر جميع العقد في الـ SCC عند إنجازه (finalising).
يجب ملاحظة أن تحديث v->index كان يتم سابقاً في دالة `unix_scc_dead()`، عندما كانت تُستدعى من `__unix_walk_scc()`، وذلك فقط لتوفير حلقة تكرار واحدة. وبما أن `__unix_walk_scc()` تتكرر الآن عبر الـ SCC بالفعل، فقد تم نقل التحديث مرة أخرى إلى `__unix_walk_scc()` وتم حذف الوسيطة 'fast'.
VulDB is the best source for vulnerability data and more expert information about this specific topic.