CVE-2026-99244 in Linux
Summary
by MITRE • 11/03/2026
In the Linux kernel, the following vulnerability has been resolved:
pid_namespace: prevent TIF_NOTIFY_SIGNAL from interrupting the reaper
Since commit 7fea700e04bd ("zap_pid_ns_processes: clear TIF_NOTIFY_SIGNAL along with TIF_SIGPENDING") zap_pid_ns_processes() clears TIF_NOTIFY_SIGNAL before every kernel_wait4() call. Otherwise kernel_wait4() doesn't sleep and returns -ERESTARTSYS if signal_pending() is true and the reaper busy-waits.
But clearing TIF_NOTIFY_SIGNAL doesn't fix it. It can get raised again. For example, klp_send_signals() sets it raw against any task that hasn't transitioned yet. And it keeps sending it until the livepatch finishes.
The sleep loop waiting for pid_allocated to drop has the same problem and it doesn't even clear anything. So a schedule() in TASK_INTERRUPTIBLE returns immediately.
Use a no_notify_signal guard. signal_pending() will ignore TIF_NOTIFY_SIGNAL and the pid namespace reaper sleeps until a child exits or free_pid() wakes it.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/03/2026
The Linux kernel contains a critical flaw within the process ID namespace management logic, specifically affecting how the PID namespace reaper handles interruptible sleep states during process termination sequences. This vulnerability stems from an incomplete mitigation strategy implemented in commit 7fea700e04bd, which attempted to prevent busy-waiting by clearing the TIF_NOTIFY_SIGNAL flag before invoking kernel_wait4. The original intent was to ensure that signal pending checks do not prematurely wake up the reaper process, thereby allowing it to sleep efficiently while waiting for child processes to exit and freeing their PIDs. However, this approach proved insufficient because the TIF_NOTIFY_SIGNAL flag is a global task state indicator that can be set by various kernel subsystems independently of the PID namespace cleanup routine.
The core technical flaw lies in the race condition between the clearing of the notification signal flag and its subsequent re-setting by other kernel components. Specifically, the livepatching infrastructure utilizes klp_send_signals to deliver signals to tasks that have not yet transitioned through a live patch update. This function sets TIF_NOTIFY_SIGNAL on affected tasks without regard for whether they are currently in the middle of PID namespace cleanup operations. Consequently, even if the reaper process clears this flag before entering an interruptible sleep state via kernel_wait4 or similar mechanisms, it can be immediately raised again by concurrent livepatch signal delivery threads. This results in a scenario where the condition signal_pending() evaluates to true despite the intention to wait for child processes, causing the scheduler to return control back to the reaper prematurely rather than allowing it to block until a relevant event occurs.
This behavior leads to a busy-wait loop within the pid namespace cleanup code. Instead of sleeping and yielding CPU resources while waiting for pid_allocated to drop or free_pid() to wake the process, the reaper continuously polls in an interruptible state that is constantly interrupted by spurious signal notifications. This not only wastes significant CPU cycles but also increases latency in PID namespace teardown operations, potentially impacting system performance during heavy container lifecycle events where namespaces are frequently created and destroyed. The issue persists because the initial fix did address the immediate symptom of kernel_wait4 returning -ERESTARTSYS incorrectly, but failed to account for external sources that can reassert the notification signal flag at any time during the wait period.
To resolve this vulnerability, a more robust guard mechanism is required that isolates the PID namespace reaper from irrelevant signal notifications during its critical waiting phase. The implemented solution introduces a no_notify_signal context or guard that temporarily disables the impact of TIF_NOTIFY_SIGNAL on the sleep logic. By ensuring that signal_pending() ignores TIF_NOTIFY_SIGNAL while the reaper is actively waiting for child processes to exit, the kernel allows schedule() in TASK_INTERRUPTIBLE mode to function correctly. This ensures the process remains asleep until a genuine wake-up event occurs, such as a child exiting or free_pid signaling availability, thereby eliminating the busy-wait condition and restoring proper resource management efficiency.
From a security and stability perspective, this vulnerability is categorized under CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, as it involves improper handling of shared task flags leading to race conditions that degrade system performance. In terms of attack surface analysis, while primarily a denial-of-service vector due to CPU exhaustion rather than privilege escalation or data leakage, it aligns with ATT&CK technique T1496: Resource Hijacking, where an attacker could potentially trigger excessive PID namespace operations combined with livepatching activities to degrade system responsiveness. Mitigation strategies involve applying the kernel patch that implements the no_notify_signal guard, ensuring that signal handling during critical kernel internal waits is properly isolated from external notification signals. System administrators should prioritize updating their Linux kernels to versions containing this fix, particularly in environments utilizing livepatching technologies alongside containerized workloads that frequently manipulate PID namespaces.