CVE-2026-98256

ملخص

في نواة Linux، تم إصلاح الثغرة الأمنية التالية: signal: منع سباق exec() قام Hyunwoo بتصحيح تتبع KASAN UAF التالي: BUG: KASAN: slab-use-after-free in __send_signal_locked+0xb27/0xba0 Write of size 8 at addr ffff888007ed80c8 by task poc/79 ... Call Trace: __send_signal_locked+0xb27/0xba0 do_send_sig_info+0xa7/0x160 do_send_specific+0x76/0xa0 __x64_sys_tgkill+0x193/0x270 ... Allocated by task 80: do_timer_create+0x1a4/0x1030 __x64_sys_timer_create+0x145/0x190 ... Freed by task 12: kmem_cache_free_bulk+0x1f8/0x4a0 kvfree_rcu_bulk+0x14f/0x1c0 kfree_rcu_work+0x128/0x1a0 ... Last potentially related work creation: kvfree_call_rcu+0x39/0x390 __flush_itimer_signals+0x211/0x320 flush_itimer_signals+0x47/0x90 begin_new_exec+0xa6b/0x28c0 اتضح أن هذا يحدث مع exec() غير قائد كما شرح Hyunwoo: تستدعي de_thread() الدالة exchange_tids() قبل release_task(leader)، لذا فإن struct pid الذي يحتفظ به مؤقت SIGEV_THREAD_ID الذي تم إنشاؤه مقابل tid القائد يشير الآن إلى الخيط الذي استدعى execve(). تُرجع pid_task() ذلك الخيط وتنجح lock_task_sighand() عليه. إذا كانت إشارة المؤقت محظورة، يبقى sigqueue الخاص بها في قائمة الانتظار على task::pending الخاص بالقائد. يمكن بعد ذلك أن يعمل انتهاء صلاحية المؤقت التالي أثناء قيام release_task() بتفريغ قائمة الانتظار. تتحقق posixtimer_send_sigqueue() مما إذا كان sigqueue في قائمة الانتظار بالفعل باستخدام list_empty() العادية، والتي تقرأ فقط list_head::next. ليست list_del_init() ذرية وتخزن INIT_LIST_HEAD() قيمة list_head::next قبل list_head::prev، لذا يمكن أن ينجح التحقق في ما بينهما. تضع list_add_tail() الإدخال في قائمة الانتظار على task::pending الخاص بالخيط الحي، ثم يقوم تخزين list_head::prev من التفريغ بالكتابة فوق رابط list_head::prev الذي قامت list_add_tail() بتعيينه للتو. لا تلغي __flush_itimer_signals() ذلك أيضًا. مع إشارة list_head::prev إلى الإدخال نفسه، فإن list_del_init() الخاصة به تخزن فقط نفس القيم مرة أخرى، لذا لا تتم إزالة الإدخال من القائمة. لا يزال موجودًا بعد إسقاط المرجع الأخير وتحرير المؤقت بواسطة RCU، وتتبع list_add_tail() الخاصة بـ tgkill() لاحق ذلك list_head::prev إلى المؤقت المحرر. ظهرت هذه المشكلة مع الالتزام الأخير الذي نقل تفريغ sigqueue خارج المنطقة المحمية بقفل sighand. اقترح Hyonwoo إصلاح ذلك باستخدام list_del_init_careful()، لكن ذلك يغطي المشكلة فقط. بعد بعض المناقشات ومحاولات متنوعة لحلها، أشار Eric إلى أنه لا يوجد سبب لتفريغ task::pending متأخرًا في release_task() ويجب القيام بذلك في exit_signals() بالفعل. نظرًا لأنه لا يمكن لأي شيء جمع وتسليم الإشارات الموضوعة في قائمة الانتظار الخاصة بمهمة تحتضر، فلا يوجد سبب لتأخيرها أكثر. ولكن يجب ضمان عدم إمكانية وضع أي إشارات في قائمة الانتظار بعد تلك النقطة. تضبط exit_signals() PF_EXITING في task::flags، والذي يمكن استخدامه كمؤشر على ذلك. عالج ذلك عن طريق: - منع وضع الإشارات في قائمة الانتظار للإشارات الخاصة بالمهمة (PIDTYPE_PID) عندما تكون PF_EXITING مضبوطة في المهمة في __send_signal_locked() وفي posixtimer_send_sigqueue(). - حماية الضبط غير المقفل لـ PF_EXITING في exit_signals() لحالة مجموعة المهام الفارغة وحالة خروج المجموعة بقفل sighand - تفريغ إشارات task::pending هناك مباشرة. حسّن ذلك بنقل قائمة الانتظار المعلقة بالكامل إلى رأس قائمة على المكدس تحت قفل sighand وتحرير الإشارات دون الاحتفاظ بالقفل. كان هناك الكثير من النقاش حول التفريغ بدون قفل وحالة exec() غير القائد على الأنظمة ذات الترتيب الضعيف. المشكلة هي أن طرفًا ثالثًا يحاول إرسال إشارة مؤقت posix يعتمد على البحث عن PID للعثور على المهمة الهدف وقد يؤدي ذلك البحث إلى القائد الجديد عندما كانت الإشارة موجهة في الأصل إلى القائد القديم. في حالة وضع الإشارة في قائمة الانتظار على القائد القديم، أثار التفريغ بدون قفل قلقًا بشأن الموقف التالي: old_leader new_leader third party A: flush_list() // list_del_in ---مقطوع---