Description
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.
Published: 2026-11-03
Score: n/a
EPSS: n/a
KEV: No
Impact: Denial of Service via kernel wait misbehavior
Action: Apply patch
AI Analysis

Impact

The vulnerability is a race condition in the Linux kernel that allows the TIF_NOTIFY_SIGNAL flag to be set and cleared in a manner that interferes with the normal operation of kernel_wait4(). Because the flag is cleared before each wait but can be re‑asserted by livepatch mechanisms such as klp_send_signals, the reaper thread can bypass its expected sleep and return –ERESTARTSYS prematurely or enter a busy‑wait loop. This race condition (CWE‑362) can cause abnormal CPU usage and severe denial of service for processes that rely on wait4() semantics.

Affected Systems

All Linux kernel versions that do not include the patch introduced by commit 7fea700e04bd are affected. Specifically, kernels that are configured for livepatching or that use the klp_send_signals module may experience the flaw. No exact kernel version list is provided, so any installation running before the commit and not yet updated is potentially vulnerable.

Risk and Exploitability

Because the flaw requires manipulation of the TIF_NOTIFY_SIGNAL flag from kernel space, the attacker must have elevated (root or kernel) privileges. The EPSS score is not available, and the vulnerability is not listed in CISA’s KEV catalog, suggesting that no public exploit is known. Nonetheless, a local privileged user could repeatedly trigger the busy‑wait and induce high CPU consumption, leading to a denial of service. The overall risk is moderate, largely dependent on the existence of an active livepatch and the privilege level of potential attackers.

Generated by OpenCVE AI on November 3, 2026 at 12:55 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the kernel to a version that includes the fix for the TIF_NOTIFY_SIGNAL race condition, specifically any release after commit 7fea700e04bd.
  • If livepatch modules such as klp_send_signals are in use, temporarily disable them or reconfigure them so that they do not set TIF_NOTIFY_SIGNAL on tasks that have not yet transitioned, until the kernel is patched.
  • Monitor kernel logs and system resource usage for abnormal patterns such as frequent –ERESTARTSYS returns or unexplained CPU spikes that could indicate an ongoing wait4() misbehavior, and investigate any suspected reaper busy‑wait loops.

Generated by OpenCVE AI on November 3, 2026 at 12:55 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Tue, 03 Nov 2026 19:30:00 +0000


Tue, 03 Nov 2026 13:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362

Tue, 03 Nov 2026 13:00:00 +0000

Type Values Removed Values Added
First Time appeared Linux linux
Vendors & Products Linux linux

Tue, 03 Nov 2026 11:30:00 +0000

Type Values Removed Values Added
Description 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.
Title pid_namespace: prevent TIF_NOTIFY_SIGNAL from interrupting the reaper
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-11-03T19:13:09.510Z

Reserved: 2026-09-25T10:25:14.403Z

Link: CVE-2026-99244

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-11-03T12:17:30.710

Modified: 2026-11-03T12:17:30.710

Link: CVE-2026-99244

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-11-03T13:00:10Z

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')