CVE-2026-64370 in Linux
Summary
by MITRE • 07/25/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/26/2026
The vulnerability identified in the Linux kernel represents a critical resource management flaw affecting the posix cpu timers subsystem. This issue manifests as a pid reference count leak within the do_cpu_nanosleep() function, which operates under the broader context of process timing and resource management mechanisms. The problem specifically impacts how the kernel handles cpu time accounting for processes through posix timers, creating a persistent memory leak that can accumulate over time and potentially lead to system instability.
The technical flaw occurs at the intersection of reference counting and error handling within the kernel's timer subsystem. When do_cpu_nanosleep() executes, it invokes posix_cpu_timer_create() which properly acquires a pid reference using get_pid() and stores this reference in timer.it.cpu.pid for later use. However, during error conditions when posix_cpu_timer_set() fails to complete successfully, the function exits prematurely without invoking posix_cpu_timer_del() to release the acquired pid reference. This creates a dangling reference that remains in memory, causing the referenced process identifier to never be properly released back to the system.
The operational impact of this vulnerability extends beyond simple memory consumption issues, as it represents a fundamental violation of proper resource management principles within kernel space operations. The leak occurs in a high-frequency code path related to cpu time measurement and process scheduling, meaning that repeated execution can lead to progressive resource exhaustion. This type of reference count leak directly correlates with CWE-401: Improper Release of Memory and aligns with ATT&CK technique T1490: Inhibit System Recovery, as the accumulation of unreleased references can contribute to system performance degradation and potential denial of service conditions.
The fix implemented addresses this by ensuring consistent error handling behavior across all exit paths within do_cpu_nanosleep(). Specifically, the solution mandates that posix_cpu_timer_del() be called before any unlock-and-return operations on error paths, establishing symmetry with the release mechanisms used in other code paths within the same function. This approach ensures proper reference count management regardless of execution flow and demonstrates adherence to kernel security best practices for resource management.
Security implications extend beyond immediate memory consumption concerns, as such leaks can potentially be exploited by malicious actors to exhaust system resources through repeated triggering of the vulnerable code path. The vulnerability affects systems running affected kernel versions where posix cpu timers are actively utilized, particularly in environments with heavy process scheduling or monitoring activities. System administrators should prioritize applying this fix to maintain proper kernel resource management and prevent potential escalation to more severe stability issues.
The resolution maintains backward compatibility while correcting the fundamental error in reference counting logic. This type of vulnerability highlights the importance of rigorous testing for error paths in kernel code, particularly in subsystems that manage critical system resources like process identifiers. The fix pattern employed follows established kernel development practices for ensuring proper cleanup during error conditions and represents a standard defensive programming approach against resource leaks in concurrent systems.
This vulnerability demonstrates the complexity inherent in kernel-level resource management where even seemingly simple reference counting operations can create cascading effects when error handling is incomplete. The solution reinforces the principle that all acquired resources must be properly released regardless of execution path, a fundamental requirement for maintaining system stability and security in operating system kernels.