Cloudanix VulnDB

CVE-2026-99244

None

CVSS

—

EPSS

0.2%

Published

Nov 3, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug can stop certain isolated groups of processes from shutting down cleanly, wasting computing power and slowing down the system.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The pid namespace reaper's sleep loop in zap_pid_ns_processes fails to block TIF_NOTIFY_SIGNAL, allowing it to be re-raised (e.g., by klp_send_signals) and causing kernel_wait4 or schedule in TASK_INTERRUPTIBLE to return immediately with -ERESTARTSYS or busy-wait instead of blocking until children exit or free_pid wakes it.

Why it matters to the business

Containers or isolated process groups may experience high CPU usage during teardown, delayed cleanup of processes, or unexpected system load when livepatching or signal-sending workloads are active.

How an attack unfolds

An attacker triggers repeated signal delivery or livepatch operations against tasks in a pid namespace while the reaper is waiting for pid_allocated to drop, preventing the reaper from sleeping and forcing continuous rescheduling or busy-waiting that can be used to degrade availability.

How to fix it

Apply the upstream kernel fix that introduces a no_notify_signal guard around the reaper's sleep loop; rebuild and deploy updated kernels to all affected systems; prioritize systems running livepatching or heavy container workloads.

How to confirm the fix worked

Confirm the no_notify_signal guard is present in zap_pid_ns_processes and the pid namespace sleep loop; test by running livepatch operations while creating and tearing down pid namespaces and verifying the reaper blocks as expected.

Typical attack path

  1. Create or enter a pid namespace with multiple child processes
  2. Initiate namespace teardown or process reaping
  3. Concurrently trigger livepatch signal delivery or other TIF_NOTIFY_SIGNAL sources
  4. Observe reaper failing to block and consuming CPU or hanging cleanup

How to detect it

Review kernel logs for repeated -ERESTARTSYS returns from kernel_wait4 in pid namespace teardown paths; look for sustained high CPU in reaper tasks during container shutdown or livepatch events; no specific post-exploitation artifacts are known.

What your security team should do

  • Patch Linux kernels to the fixed version containing the no_notify_signal change as soon as available
  • Monitor CPU usage and process cleanup latency in container orchestration environments
  • Limit livepatch operations on systems with high pid namespace churn until patched

The record

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.

Affected packages

Ecosystem Package Introduced Fixed