CVE-2026-64370
NoneCVSS
—
EPSS
0.1%
Published
Jul 25, 2026
CISA due date
—
Cloudanix analysis
A flaw in some Linux systems can let someone with local access gradually drain system resources until the machine slows down or crashes.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Denial of service
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Medium
What it actually does
This is a Linux kernel denial-of-service class flaw in the POSIX CPU timer nanosleep path. When do_cpu_nanosleep() creates a CPU timer, it takes a reference to a pid object. If the subsequent timer setup fails, the vulnerable error path returns without releasing that reference. Repeatedly triggering this failure path can leak kernel pid references over time, consuming kernel memory and preventing normal cleanup of process-related kernel objects. The practical impact is local resource exhaustion rather than code execution or privilege escalation based on the available description.
Why it matters to the business
Affected Linux systems may become unstable or require reboot if a local user or workload can repeatedly trigger the vulnerable kernel path and exhaust kernel resources. The most likely operational consequence is denial of service on shared Linux hosts, multi-user systems, CI/build infrastructure, container hosts, or environments running untrusted workloads. The current EPSS score is very low, it is not listed in CISA KEV, and there is no known public exploit maturity indicated, so broad internet-scale exploitation is not expected; however, kernel resource leaks are still important to remediate during normal Linux patch cycles, especially on systems where untrusted local code can run.
How an attack unfolds
An attacker needs the ability to execute code locally on a vulnerable Linux system. They invoke POSIX CPU timer or nanosleep-related functionality in a way that causes posix_cpu_timer_create() to acquire a pid reference and then causes posix_cpu_timer_set() to fail. Because the vulnerable error path does not release the pid reference, each failed attempt leaves behind a leaked kernel reference. By repeating this sequence many times, the attacker can gradually consume kernel resources associated with pid objects. Over time this may degrade system performance, interfere with process lifecycle cleanup, exhaust memory or other kernel accounting limits, and potentially force administrators to restart the host to recover.
How to fix it
Upgrade to a Linux kernel version that includes the fix for the posix-cpu-timers do_cpu_nanosleep() pid reference leak. If using a distribution kernel, apply the relevant vendor security or stable kernel update rather than relying only on upstream version numbers. Because no affected product list or fixed package versions were provided, administrators should consult their Linux distribution advisories for CVE-2026-64370 or for the upstream fix titled "posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path." Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting execution of untrusted workloads, applying container and job runtime limits, using cgroup memory and process controls, and monitoring for abnormal process, timer, and kernel memory behavior. A reboot may be required after kernel package installation to load the fixed kernel.
How to confirm the fix worked
Confirm the running kernel, not just the installed package, has been updated to a build containing the fix. Validate by checking distribution package changelogs or security advisories for the referenced CVE or patch title, then rebooting into the updated kernel and verifying with uname or package tooling. Exposure exists if the system is running a vulnerable kernel build and permits local users, containers, jobs, or application code to exercise POSIX CPU timer functionality. Because the flaw is a resource leak on an error path, validation should focus on kernel version/build provenance and vendor advisory status rather than remote scanning. In controlled test environments only, stress testing the affected code path before and after patching can confirm that repeated failed timer setup no longer causes progressive kernel resource growth.
Typical attack path
- Obtain local code execution as an unprivileged user, compromised service account, containerized workload, or other workload on a vulnerable Linux kernel.
- Run a program that repeatedly exercises the POSIX CPU timer nanosleep path.
- Force or induce the timer setup operation to fail after the kernel has already taken a pid reference.
- Repeat the failing operation at high volume to accumulate leaked kernel pid references.
- Continue until kernel memory pressure, process-management issues, or host instability cause service degradation or denial of service.
How to detect it
Look for signs of local denial-of-service activity rather than network exploitation. Useful sources include auditd syscall telemetry, endpoint detection process telemetry, kernel logs, systemd journal, resource monitoring, container runtime logs, and host performance metrics. Investigate periods of unexplained kernel memory growth, increasing slab usage, process-management anomalies, high rates of timer/nanosleep-related syscalls, or host instability caused by a local process. If audit rules or eBPF telemetry are available, search for processes making unusually frequent calls related to clock_nanosleep, nanosleep, timer_create, timer_settime, or CPU-time clocks, especially when correlated with failed syscall returns and rising kernel memory pressure. Review local user activity, scheduled jobs, CI tasks, containers, and recently introduced binaries around the time resource exhaustion began. There are no known public threat actors, ransomware campaigns, or stable file/network indicators associated with this vulnerability based on the provided data.
- do_cpu_nanosleep
- posix_cpu_timer_create
- posix_cpu_timer_set
- posix_cpu_timer_del
- clock_nanosleep
- nanosleep
- timer_create
- timer_settime
- kernel: Out of memory
- kernel: oom-killer
- systemd-journald: Suppressed
- audit: ANOM_ABEND
What your security team should do
- Prioritize patching Linux hosts that run untrusted or semi-trusted local code, including shared servers, container platforms, developer workstations, CI/CD runners, batch-processing nodes, and multi-tenant compute infrastructure.
- Track distribution-specific advisories and update to a kernel build that includes the upstream posix-cpu-timers do_cpu_nanosleep() cleanup fix.
- After installing the kernel update, reboot affected systems and verify the active kernel is the fixed version.
- Until patched, restrict local code execution where feasible and apply cgroup, container, process-count, CPU, and memory limits to reduce denial-of-service blast radius.
- Monitor for unusual growth in kernel memory usage, process table pressure, repeated timer-related syscall activity, unexplained host instability, and local processes consuming excessive syscall rates.
- Because EPSS is currently low, the issue is not in CISA KEV, and no exploit maturity is indicated, handle as a scheduled kernel remediation item unless the environment runs untrusted local workloads, in which case accelerate patching.
The record
In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path In do_cpu_nanosleep(), posix_cpu_timer_create() takes a pid reference via get_pid() and stores it in timer.it.cpu.pid. If the subsequent posix_cpu_timer_set() call fails, the function returns immediately without calling posix_cpu_timer_del() to release the pid reference, causing a leak. Fix it by calling posix_cpu_timer_del() before the unlock-and-return on the error path, consistent with the other exit paths in the same function.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|