CVE-2026-64426 in Linux
الملخص
بحسب VulDB • 25/07/2026
في نواة لينكس، تم حل الثغرة التالية:
io_uring/nop: إصلاح تسرب مرجع الملف مع IOSQE_FIXED_FILE
تختار دعم استحواذ ملف NOP بين ملف ثابت (مسجل) وملف عادي يتم الحصول عليه عبر fget() بناءً على علم IORING_NOP_FIXED_FILE الخاص به في sqe->nop_flags. ومع ذلك، يُضبط REQ_F_FIXED_FILE للطلب بشكل مستقل عن العلم العام IOSQE_FIXED_FILE الموجود في SQE أثناء تهيئة الطلب، قبل أن يعمل معالج الإصدار (issue handler).
إذا تم تقديم NOP مع تعيين IOSQE_FIXED_FILE (وبالتالي يتم تعيين REQ_F_FIXED_FILE) ولكن بدون IORING_NOP_FIXED_FILE، فإن io_nop() يتبع المسار العادي ويحصل على مرجع حقيقي عبر io_file_get_normal(). عند الاكتمال، يقوم io_put_file() بإسقاط المرجع فقط عندما يكون REQ_F_FIXED_FILE غير مضبوط (clear)، وبالتالي لا يتم إطلاق ملف fget()'d أبداً مما يؤدي إلى تسرب:
BUG: memory leak unreferenced object 0xffff88800f42c240 (size 176): kmem_cache_alloc_noprof+0x358/0x440 alloc_empty_file+0x57/0x180 path_openat+0x44/0x1e50 do_file_open+0x121/0x200 do_sys_openat2+0xa7/0x150 __x64_sys_openat+0x82/0xf0
يتم اتخاذ القرار بين استحواذ الملف الثابت والعادي بناءً على REQ_F_FIXED_FILE، بالطريقة نفسها التي يتبعها io_assign_file() لكل رمز عملية (opcode) آخر، ويتم دمج IORING_NOP_FIXED_FILE مع REQ_F_FIXED_FILE في وقت التحضير (prep time).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.