UBUNTU-CVE-2026-99244: Medium severity ubuntu/linux vulnerability
In the Linux kernel, the following vulnerability has been resolved: pidnamespace: prevent TIFNOTIFYSIGNAL from interrupting the reaper Since commit 7fea700e04bd ("zappidnsprocesses: clear TIFNOTIFYSIGNAL along with TIFSIGPENDING") zappidnsprocesses() clears TIFNOTIFYSIGNAL before every kernelwait4() call. Otherwise kernelwait4() doesn't sleep and returns -ERESTARTSYS if signalpending() is true and the reaper busy-waits. But clearing TIFNOTIFYSIGNAL doesn't fix it. It can get raised again. For example, klpsendsignals() 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 pidallocated to drop has the same problem and it doesn't even clear anything. So a schedule() in TASKINTERRUPTIBLE returns immediately. Use a nonotifysignal guard. signalpending() will ignore TIFNOTIFYSIGNAL and the pid namespace reaper sleeps until a child exits or freepid() wakes it.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Use a no_notify_signal guard in the PID namespace reaper so signal_pending() ignores TIF_NOTIFY_SIGNAL and the reaper sleeps until a child exits or free_pid() wakes it.
Event History
Frequently Asked Questions
Which Ubuntu kernel packages are identified as affected?
The advisory lists ubuntu/linux, ubuntu/linux-fips, ubuntu/linux-aws, ubuntu/linux-azure, ubuntu/linux-gcp, ubuntu/linux-oracle, ubuntu/linux-aws-fips, and ubuntu/linux-azure-fips.
Under what condition can the pid namespace reaper busy-wait?
The issue occurs when TIF_NOTIFY_SIGNAL is raised while zap_pid_ns_processes() is waiting through kernel_wait4() or while waiting for pid_allocated to drop. The interruptible wait can return immediately, causing the reaper to busy-wait instead of sleeping until a child exits or free_pid() wakes it.
Is clearing TIF_NOTIFY_SIGNAL before kernel_wait4() sufficient to prevent the issue?
No. TIF_NOTIFY_SIGNAL can be raised again after it is cleared, including by klp_send_signals() while livepatching is still in progress. The resolution uses a no_notify_signal guard so signal_pending() ignores TIF_NOTIFY_SIGNAL during the reaper's wait.