CVE-2026-53352

What it actually does

This is a Linux kernel race condition in job-control signal handling during multi-threaded process teardown. If a thread group has a pending stop signal while one thread concurrently executes execve(), zap_other_threads() terminates the other threads and resets the group stop count, but previously failed to clear stale JOBCTL_PENDING_MASK state on the calling thread. When that thread returns to user mode, it can consume the stale stop state and attempt to decrement an already-zero signal->group_stop_count, triggering a kernel warning in task_participate_group_stop(). The most likely technical outcome is a local kernel warning and potential denial of service on systems configured to panic on kernel warnings; the description does not indicate privilege escalation, remote code execution, or data disclosure.

Why it matters to the business

The main operational risk is local disruption: an unprivileged local workload may be able to trigger repeated kernel warnings and, on hardened or debugging-oriented systems where kernel warnings cause a panic, crash the host. This can affect availability of Linux servers, containers, CI runners, developer workstations, and multi-tenant compute nodes. The current exploitation likelihood appears low because EPSS is very low, the issue is not in the CISA KEV catalog, is not known to be used in ransomware campaigns, and no public exploit maturity is reported; however, kernel stability bugs should still be remediated through normal patch cycles, especially on systems where panic_on_warn is enabled.

How an attack unfolds

An attacker needs the ability to run code locally on a vulnerable Linux system. They create or control a multi-threaded process, arrange for a group stop signal such as SIGSTOP to be delivered while the process is multi-threaded, and concurrently have one thread call execve(). During execve(), the kernel de-threads the process and calls zap_other_threads() to terminate the other threads. In vulnerable kernels, the group stop state is cleared for the other threads but not for the calling thread. After execve() completes, the surviving thread returns toward user mode, observes stale job-control stop flags, re-enters the group-stop handling path, and triggers a WARN condition because the group stop count has already been reset to zero. If the system is configured to panic on WARN, this warning can become a host crash; otherwise it is typically observable as a kernel warning in logs.

How to fix it

Upgrade to a Linux kernel build that includes the fix clearing JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(). Because no product-specific affected or fixed versions were provided, use the fixed kernel packages or vendor advisory applicable to each distribution, appliance, container host, or embedded Linux build. Prioritize internet-facing compute platforms that run untrusted local workloads, shared hosting, Kubernetes/container worker nodes, CI/CD runners, and systems configured with kernel.panic_on_warn=1. If immediate patching is not possible, reduce exposure by limiting untrusted local shell access, isolating untrusted workloads, restricting container escape paths and privileged containers, and reviewing whether panic_on_warn is required in production. Avoid treating sysctl changes as a full fix; disabling panic_on_warn may reduce crash impact but does not remove the underlying kernel bug.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package includes the vendor backport or upstream commit for clearing JOBCTL_PENDING_MASK in zap_other_threads(). Validate that the booted kernel, not just the installed package, is updated using standard OS inventory commands such as uname -r and distribution package tooling. Check vendor advisories or changelogs for references to signal handling, zap_other_threads(), JOBCTL_PENDING_MASK, or this CVE. After patching and rebooting where required, ensure no new kernel warnings referencing task_participate_group_stop or signal->group_stop_count appear in dmesg, journald, /var/log/kern.log, or equivalent kernel log sources. For exposure validation, inventory Linux kernel versions across fleets and compare them with distribution-specific fixed releases.

Typical attack path

1. Gain local code execution as any user or through a workload/container that can create threads and send signals within its process permissions.
2. Start a multi-threaded process under attacker control.
3. Trigger a stop signal, such as SIGSTOP, against the process while multiple threads are active.
4. Race one thread into execve() while the group stop state is pending.
5. Cause zap_other_threads() to tear down the thread group while leaving stale job-control flags on the execve() caller.
6. Allow the surviving thread to return to user mode and process pending signal state.
7. Trigger a kernel warning in task_participate_group_stop(); on systems configured with panic_on_warn, cause a kernel panic and denial of service.

How to detect it

Look for evidence in kernel log sources rather than network telemetry. Useful sources include dmesg, /dev/kmsg captures, journald kernel facility logs, /var/log/kern.log, /var/log/messages, crash dump metadata, hypervisor reset events, and EDR telemetry that records kernel panics or process crashes. Search for warnings that include task_participate_group_stop, do_signal_stop, get_signal, signal->group_stop_count == 0, or zap_other_threads. If panic_on_warn is enabled, also review unexpected host reboots or kernel panic records shortly after such warnings. Correlate timestamps with auditd, process execution, shell history where available, container runtime logs, Kubernetes pod events, and systemd journal entries to identify a local multi-threaded process that received stop signals and executed a new program around the time of the warning. Because the issue is local and race-dependent, absence of these logs does not prove non-exploitation if kernel logs rotate quickly or crash dumps are not retained.

• sig->group_stop_count == 0
• WARNING: CPU:
• task_participate_group_stop+
• kernel/signal.c:373
• do_signal_stop+
• get_signal+
• arch_do_signal_or_restart+
• exit_to_user_mode_loop+
• entry_SYSCALL_64_after_hwframe
• zap_other_threads
• JOBCTL_STOP_PENDING
• JOBCTL_STOP_CONSUME
• JOBCTL_PENDING_MASK
• kernel.panic_on_warn = 1
• panic_on_warn

What your security team should do

• Prioritize patching shared Linux hosts, container worker nodes, CI runners, and any systems that execute untrusted or semi-trusted local code.
• Inventory systems with kernel.panic_on_warn enabled because they have higher denial-of-service impact from this bug.
• Monitor kernel logs for WARN traces involving task_participate_group_stop, do_signal_stop, get_signal, and signal->group_stop_count.
• Correlate any matching kernel warning with process execution, user session, container, and audit logs to identify the local workload that triggered it.
• Apply vendor kernel updates and reboot into the fixed kernel; confirm the running kernel version after reboot.
• Where patching is delayed, reduce local attack surface by limiting interactive access, privileged containers, and untrusted workload co-tenancy.
• Treat repeated triggering as a potential local denial-of-service attempt even though there is no current evidence of broad exploitation, KEV listing, or ransomware use.