原文

Linuxカーネルにおいて、以下の脆弱性が解決されました。signal: zap_other_threads()内で呼び出し元スレッドのJOBCTL_PENDING_MASKをクリアするマルチスレッドプロセスが停止シグナル（例：SIGSTOP）を受け取ると、do_signal_stop()は全てのスレッドに対してJOBCTL_STOP_PENDINGおよびJOBCTL_STOP_CONSUMEを設定し、signal-＞group_stop_countにスレッド数をセットします。もしスレッドの一つが同時にexecve()を呼び出した場合、de_thread()はzap_other_threads()を呼び出して他の全スレッドを終了させます。zap_other_threads()は保留中のグループ停止状態を中止するためにsignal-＞group_stop_countを0にリセットし、他のスレッドのJOBCTL_PENDING_MASKをクリアします。しかし、呼び出し元スレッドのジョブ制御フラグのクリアは行いません。execve()の完了後、呼び出し元スレッドはユーザーモードに戻り、保留中のシグナルをチェックします。そこで古いJOBCTL_STOP_PENDINGフラグを検出すると、do_signal_stop()を呼び出しtask_participate_group_stop()を実行します。JOBCTL_STOP_CONSUMEが依然としてセットされているため、すでにゼロであるsignal-＞group_stop_countを減らそうとし、その結果以下の警告が発生します。sig-＞group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: ＜TASK＞ do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f ＜/TASK＞ この競合状態は、zap_other_threads()内で呼び出し元スレッドのJOBCTL_PENDING_MASKをクリアすることで修正され、スレッドグループ破棄後に古いジョブ制御状態を保持しないようにしました。これはzap_process()やcomplete_signal()など、スレッドグループを解体しグループ停止を中止する他の関数とも整合しています。これらの関数は現在のスレッドを含む全てのスレッドのフラグを正しくクリアしています。