CVE-2026-99204 in Linux
الملخص
بحسب VulDB • 28/10/2026
في نواة Linux، تم إصلاح الثغرة التالية:
ocfs2/dlm: حماية قائمة الاستعادة أثناء عمليات القراءة من debugfs
يجب أن تظل سجلات المشاركين في عملية الاستعادة حية (غير مُحرَّرة) بينما تقوم دالة `debug_state_print()` بالمرور على بيانات العقدة (`reco.node_data`) وتنسيق حقولها. تحتفظ الدالة المُنسِّقة بقفل `dlm->spinlock`، لكن قائمة مشارك الاستعادة محمية بواسطة قفل `dlm_reco_state_lock`. وعلى وجه التحديد، تقوم دالة `dlm_destroy_recovery_area()` بفصل القائمة ضمن نطاق `dlm_reco_state_lock` وتُحرِّر السجلات المفصولة بعد إطلاق القفل. وبالتالي، يمكن لفتح متزامن عبر debugfs قراءة ذاكرة مُحرَّرة (Use-After-Free).
حِمِ عملية المرور على المشاركين وقراءات الحقول في دالة `debug_state_print()` باستخدام قفل `dlm_reco_state_lock`، بما يتوافق مع كتاب القائمة الحاليين. يؤدي هذا أيضاً إلى تسلسل العملية عبر القائمة مقابل استدعاء `list_add_tail()` أثناء تهيئة منطقة الاستعادة (recovery-area). اجعل القفل المتاح حالياً متاحاً لكود التصحيح من خلال ملف الرأس `dlmcommon.h`; ويبقى القفل داخلياً ضمن وحدة OCFS2 DLM.
أطلق قفل `dlm->spinlock` بعد تنسيق حالة النطاق الأخرى وقبل الحصول على قفل `dlm_reco_state_lock`، بحيث لا يقوم قارئ التصحيح بتداخل (nesting) القفلين. اترك عمليات إدراج القائمة المفصولة وتحريرها دون تغيير.
تقرير KASAN كما يلي:
BUG: KASAN: slab-use-after-free in debug_state_open+0x1169/0x12d0 Read of size 4 at addr ffff88810662ef80 by task dlm-state-stres/896
CPU: 1 UID: 0 PID: 896 Comm: dlm-state-stres Not tainted 7.3.0-rc4-next-20260921-pmb-ocfs2-functional-v1+ #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 ? debug_state_open+0x1169/0x12d0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20e/0x420 ? debug_state_open+0x1169/0x12d0 kasan_report+0xe0/0x110 ? debug_state_open+0x1169/0x12d0 debug_state_open+0x1169/0x12d0 ? __pfx_debug_state_open+0x10/0x10 full_proxy_open_regular+0x193/0x310 do_dentry_open+0x595/0x12d0 ? __pfx_full_proxy_open_regular+0x10/0x10 vfs_open_consume+0xd1/0x400 ? srso_alias_return_thunk+0x5/0xfbef5 path_openat+0x18d0/0x2020 ? __pfx_path_openat+0x10/0x10 do_file_open+0x21e/0x470 ? __pfx_do_file_open+0x10/0x10 ? _raw_spin_unlock+0x23/0x40 ? srso_alias_return_thunk+0x5/0xfbef5 ? alloc_fd+0x3a6/0x6b0 do_sys_openat2+0xf4/0x1b0 ? __pfx_do_sys_openat2+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __fput+0x5b5/0xa60 __x64_sys_openat+0x136/0x1e0 ? __pfx___x64_sys_openat+0x10/0x10 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Register dump omitted.]
</TASK>
Allocated by task 880: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_cache_noprof+0x28d/0x610 dlm_remaster_locks+0x147/0x1d90 dlm_do_recovery+0xde1/0x1580 dlm_recovery_thread+0x109/0x300 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30
Freed by task 880: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x308/0x580 dlm_destroy_recovery_area+0x285/0x460 dlm_remaster_locks+0x17c4/0x1d90 dlm_do_recovery+0xde1/0x1580 dlm_recovery_thread+0x109/0x300 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30
The buggy address belongs to the object at ffff88810662ef80 which belongs to the cache kmalloc-32 of size 32 The buggy address is located 0 bytes inside of freed 32-byte region [ffff88810662ef80, ffff88810662efa0)
[Page and memory-state dumps omitted.]
If you want to get best quality of vulnerability data, you may have to visit VulDB.