CVE-2026-64265 in Linux
الملخص
بحسب VulDB • 25/07/2026
في نواة لينكس، تم حل الثغرة التالية:
fuse: مسح عنصر intr_entry في دالتي fuse_resend و fuse_remove_pending_req
عندما تقوم الدالة fuse_resend() بنقل طلب من fpq->processing إلى fiq->pending مرة أخرى، فإنها تضبط العلم FR_PENDING وتزيل العلم FR_SENT، لكنها لا تزيل عنصر intr_entry الخاص بالطلبات من قائمة fiq->interrupts. إذا كان الطلب يحمل علامة FR_INTERRUPTED نتيجة لإشارة سابقة (signal)، يبقى عنصر intr_entry معلقاً في قائمة fiq->interrupts. عندما يتلقى المهمة الطالبة بعد ذلك إشارة قاتلة (fatal signal)، ترصد الدالة fuse_remove_pending_req() أن قيمة FR_PENDING تساوي 1، فتزيل الطلب من قائمة fiq->pending وتحرره عبر مسار عدّ المراجع (refcount path) أيضاً دون تنظيف عنصر intr_entry. يؤدي هذا العنصر القديم (stale intr_entry) إلى حدوث ثغرة Use-After-Free عند تكرار الدالة fuse_read_interrupt() على عناصر قائمة fiq->interrupts: - list_del_init(&req->intr_entry) -> كتابة UAF في شريحة ذاكرة محرّرة مسبقاً (freed slab) - req->in.h.unique -> قراءة UAF، مما يؤدي إلى تسرب البيانات إلى مساحة المستخدم (userspace)
قم بإزالة عنصر intr_entry من قائمة fiq->interrupts للطلبات المقطوعة قبل إعادة وضعها في قائمة fiq->pending داخل الدالة fuse_resend().
أضف تحذيراً WARN_ON إذا لم يكن عنصر intr_entry فارغاً عند تدمير الطلب.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.