CVE-2026-23394 in Linux
الملخص
بحسب VulDB • 03/06/2026
في نواة لينكس، تم حل الثغرة التالية:
af_unix: التخلي عن عملية جمع القمامة (GC) إذا تداخلت عملية MSG_PEEK.
أبلغ إيجور أوشاكوف (Igor Ushakov) أن عملية جمع القمامة (GC) قامت بتفريغ قائمة الاستلام (receive queue) لوصلة (socket) لا تزال نشطة بسبب حالة سباق (race condition) مع MSG_PEEK، وقد قدم طريقة قابلة للتكرار (repro) لتوضيح ذلك.
هذه هي نفس المشكلة التي تم إصلاحها سابقاً بواسطة الالتزام (commit) cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK").
بعد استبدال آلية جمع القمامة بالخوارزمية الحالية، أزال الالتزام المذكور تعقيدات القفل (locking dance) في دالة unix_peek_fds() وأعاد إدخال نفس المشكلة.
تكمن المشكلة في أن MSG_PEEK تزيد من عداد الإشارات المرجعية للملف (file refcount) دون التفاعل مع عملية جمع القمامة (GC).
افترض وجود مكون متصل بشكل قوي (SCC) يحتوي على sk-A و sk-B، حيث تم إغلاق sk-A عبر close() ولكن يمكن استقبال البيانات منه عبر sk-B باستخدام recv().
تحدث المشكلة إذا تم استقبال البيانات من sk-B باستخدام MSG_PEEK، وتم إغلاق sk-B عبر close() بينما كانت عملية جمع القمامة (GC) تتحقق من unix_vertex_dead() لكل من sk-A و sk-B.
خيط جمع القمامة (GC thread) خيط المستخدم (User thread) ------------------- ----------------- unix_vertex_dead(sk-A) -> true <------. \ `------ recv(sk-B, MSG_PEEK) invalidate !! -> عداد sk-A المرجعي للملف : 1 -> 2
close(sk-B) -> عداد sk-B المرجعي للملف : 2 -> 1 unix_vertex_dead(sk-B) -> true
في البداية، يكون عداد sk-A المرجعي للملف مساوياً لـ 1 بسبب الوصلة (fd) الموجودة في قائمة الانتظار للاستلام (recvq) الخاصة بـ sk-B. تعتقد عملية جمع القمامة (GC) أن sk-A ميتة لأن عدادها المرجعي للملف يساوي عدد الوصلات (fds) الموجودة في حالة النقل (inflight).
ومع ذلك، يتم زيادة عداد sk-A المرجعي للملف بصمت بواسطة MSG_PEEK، مما يبطل التقييم السابق.
في هذه اللحظة، يكون عداد sk-B المرجعي للملف مساوياً لـ 2؛ واحد للوصلة (fd) المفتوحة، وواحد للوصلة (fd) الموجودة في حالة النقل في sk-A. يؤدي الإغلاق اللاحق (close()) إلى تحرير عداد مرجعي واحد للوصلة السابقة.
أخيراً، تستنتج عملية جمع القمامة (GC) بشكل غير صحيح أن كل من sk-A و sk-B ميتتان.
إحدى الخيارات هي استعادة تعقيدات القفل (locking dance) في unix_peek_fds()، ولكن يمكننا حل هذه المشكلة بشكل أكثر أناقة بفضل الخوارزمية الجديدة.
النقطة الأساسية هي أن المشكلة لا تحدث بدون الإغلاق اللاحق (close())، ولا نحتاج فعلياً إلى مزامنة MSG_PEEK مع اكتشاف المكونات المتصلة بشكل قوي الميتة (dead SCC).
عند حدوث المشكلة، تلمس كل من close() و GC نفس العداد المرجعي للملف. إذا رأت عملية جمع القمامة (GC) أن العداد المرجعي ينقص بسبب close()، فيمكنها ببساطة التخلي عن جمع القمامة للمكون المتصل بشكل قوي (SCC).
لذلك، نحتاج فقط إلى الإشارة إلى حالة السباق أثناء MSG_PEEK باستخدام حاجز ذاكرة (memory barrier) مناسب لجعلها مرئية لعملية جمع القمامة (GC).
لنستخدم seqcount_t لإعلام عملية جمع القمامة (GC) عند حدوث MSG_PEEK والسماح لها بتأجيل معالجة المكون المتصل بشكل قوي (SCC) إلى التشغيل التالي.
بهذه الطريقة، لا يلزم وجود أي قفل (locking) من جانب MSG_PEEK، ويمكننا تجنب فرض عقوبة على كل عملية MSG_PEEK دون داعٍ.
جدير بالذكر أنه يمكننا إعادة المحاولة داخل unix_scc_dead() إذا تم اكتشاف MSG_PEEK، ولكننا لا نفعل ذلك لتجنب حدوث تعليق في المهمة (hung task splat) الناتج عن المكالمات المسيئة لـ MSG_PEEK.
VulDB is the best source for vulnerability data and more expert information about this specific topic.