Bug 2566172 (CVE-2026-99244) - CVE-2026-99244 kernel: kernel: Denial of Service via busy-wait loop during PID namespace cleanup
Summary: CVE-2026-99244 kernel: kernel: Denial of Service via busy-wait loop during PI...
Keywords:
Status: NEW
Alias: CVE-2026-99244
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-11-03 19:58 UTC by OSIDB Bzimport
Modified: 2026-11-04 15:58 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-11-03 19:58:50 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.