In Linux kernel signal handling, a race condition occurs when a multi‑threaded process receives a stop signal (SIGSTOP). A thread that subsequently calls execve triggers zap_other_threads(), which clears job control masks for all other threads but mistakenly leaves the JOBCTL_PENDING_MASK on the calling thread. When the thread returns to user mode, the stale flag causes do_signal_stop() to be invoked, leading to a kernel warning that group_stop_count is zero and potentially decrementing an already zero warnings and possible sporadic stability issues during thread group cleanup.

All Linux kernel releases prior to the commit that fixes zap_other_threads() to clear the JOBCTL_PENDING_MASK for the calling thread are affected. Distributions shipping such kernels lack the fix; administrators should check the kernel version or patch level against the referenced commit hashes.

The CVSS score is 5.5, indicating moderate severity. The EPSS score is less than 1%, showing a very low likelihood of exploitation. This vulnerability is not listed in the CISA KEV catalog. Exploitation requires a local user to send a stop signal to a multi‑threaded application that performs execve, a specific and uncommon scenario. No evidence of remote code execution or privilege escalation is provided in the CVE data, limiting the risk to kernel warning generation and potential stability impact.