---
id: "CVE-2026-99249"
kind: "vulnerability"
aliases: ["CVE-2026-99249"]
title: "Linux kernel: suspend can hang while a pid namespace init waits"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["containers", "infrastructure", "linux-kernel", "suspend"]
not_affected_if: ["no-pid-namespaces"]
published_at: "2026-11-03T12:17:31+00:00"
first_seen_at: "2026-11-03T12:20:39+00:00"
updated_at: "2026-11-03T12:22:58+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99249", "first_seen_at": "2026-11-03T12:20:39+00:00"}]
---

# Linux kernel: suspend can hang while a pid namespace init waits

When the init process of a pid namespace exits, the kernel waits for the other processes in that namespace to finish, and that wait is not freezable. A tracer outside the namespace that never reaps its traced zombies can keep the wait going indefinitely, so suspend fails.

_Summary, check and fix written by a model from the sources; labelled as such._

## Timeline

- 2026-11-03T12:20:39+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99249

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

pid_namespace: make zap_pid_ns_processes() freezable

When the init of a pid namespace exits, zap_pid_ns_processes() waits
until all other pids in the namespace are freed. A tracer outside the
namespace that does not reap its traced zombies keeps those pids
allocated, so this wait has no upper bound, and while it lasts every
suspend attempt fails:

  Freezing user space processes failed after 20.006 seconds (2 tasks refusing to freeze, wq_busy=0):

Neither wait is freezable. The first loop sleeps in do_wait(), which
returns -ERESTARTSYS on the freezer's fake signal; the loop then clears
TIF_SIGPENDING and waits again without ever freezing. The final loop
sleeps in TASK_INTERRUPTIBLE, and since nothing clears TIF_SIGPENDING
there, schedule() returns immediately after the first freeze attempt
and the task spins until the wait ends.

Sleep in TASK_INTERRUPTIBLE | TASK_FREEZABLE in do_wait(), so that the
freezer can freeze tasks waiting there directly, and in TASK_IDLE |
TASK_FREEZABLE in the final loop, like coredump_task_exit() does.

This was hit with Chromium-based browsers: crashpad ptrace-attaches the
threads of a crashed renderer, which is a pid namespace init, and does
not reap those killed during the dump.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_