Skip to main content
← Vulnerabilities

pid_namespace: make zap_pid_ns_processes() freezable

Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.

—Not rated
Exploited
No known exploitation
Fix
No fix listed
Who is exposed
Not reported
25Pcve.now Index 25 of 100 · methodology v3 · provisional
  • Exploitation?/40Exploitation: unknown (data gap). No CISA SSVC exploitation rating yet
  • Exposure?/25Exposure: unknown (data gap). No advisory context yet
  • Reach20/20Affects Linux kernel (software on nearly every server, desktop or phone)
  • Severity?/10Severity: unknown (data gap). No CVSS score or vendor rating
  • No patch5/5No patch listed yet

What would change the score

  • Would score about 80 if added to CISA KEV
  • Would score about 75 if CISA's SSVC rates exploitation active
  • Would score about 47 if advisories confirm default setups are exposed

CVE-2026-99249 is not in CISA's Known Exploited Vulnerabilities (KEV) catalog. No public exploit code is tracked. It affects Linux; no fixed version is listed yet.

Published
Last modified
Published
Not listed in CISA KEV
25/100 · provisional
None on Exploit-DB, Metasploit or GitHub

Summary

The Linux kernel's process and PID namespace handling is affected, where a namespace's init process exiting can leave the system unable to suspend. A tracer outside the namespace that never reaps its traced zombie processes can block this exit path indefinitely, causing suspend attempts to fail and the system to remain stuck until the tracer releases them.

Read the original description

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.

Timeline

  1. CVE published
  2. First seen by cve.now

Affected versions

  • Linux Linux

    Version range not reported

  • Linux Linux

    2.6.24

Evidence 6

  1. Link
  2. Link
  3. Link
  4. Link
  5. Link
  6. Link

Corrections

None so far.

Something wrong on this page? Report an error. Every fix is listed here.

FAQ

Questions about CVE-2026-99249

Is CVE-2026-99249 being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data

Which versions are affected by CVE-2026-99249?

Linux: version 2.6.24.Source: cve.now feed data