CVE-2026-68095 in Linux
الملخص
بحسب VulDB • 10/08/2026
في نواة لينكس، تم حل الثغرة التالية:
fuse-uring: إصلاح حالة السباق (race condition) بين التسجيل وإلغاء الاتصال
يؤدي هذا الإصلاح إلى معالجة حالة السباق هذه: - الخيط أ: io_uring_enter -> تسجيل sqe -> fuse_uring_create_ring_ent -> تخصيص ent ولكن دون الحصول على queue_ref بعد. - الخيط ب: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() لا تفعل شيئاً (no-op) بسبب كون مرجع الطابور (queue ref) يساوي 0. - الخيط أ: يحصل على queue_ref، ويصبح قيمة queue_ref الآن 1، وتُنفذ بقية منطق دالة fuse_uring_do_register(). - الخيط ب: تعود الدالة fuse_chan_abort()، ثم تعمل الدالة fuse_chan_wait_aborted() وتستدعي "wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0;)".
سيعلق خيط الإلغاء/فك التثبيت (abort/unmount thread) إلى الأبد في حالة غير قابلة للقتل، حيث لن يقوم أي شيء بإنقاص قيمة queue_refs أو إيقاظ stop_waitq، مما يؤدي أيضاً إلى تسرب الـ ring وqueue وent.
يتم حل هذه المشكلة عن طريق التحقق من fch->connected تحت قفل fch->lock بعد أن يكون ent المُنشئ قد حصل على عداد مرجعي (ref count) للطابور. يضمن هذا أنه في السيناريو المذكور أعلاه، نضمن إما إطلاق مرجع الطابور وإيقاظ stop_waitq (في حال كانت fuse_chan_wait_aborted() تنتظر بالفعل) داخل دالة fuse_uring_do_register() عند اكتشاف أن !fch->connected صحيح، أو إذا تم إلغاء الاتصال بعد الفحص، فإننا نضمن تشغيل عامل التفكيك غير المتزامن (async teardown worker) في الخلفية لتنظيف ents وإنقاص المرجع الخاص بـ ent على الطابور، مما سيؤدي إلى فك حجب تفكيك الطابور وring النهائي.
VulDB is the best source for vulnerability data and more expert information about this specific topic.