CVE-2026-98552 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix a refcount leak in attach_perf_ctx_data()
The attach_perf_ctx_data() can race on global and !global cases. The global case is protected by global_ctx_data_rwsem and shares a single reference count using perf_ctx_data.global field.
But when it races with !global case, it may miss to set the global field and result in a reference count leak.
CPU1 CPU2 ---------------------------------------------------------------- attach_task_ctx_data(.global=1) attach_task_ctx_data(.global=0) cd1 = alloc_perf_ctx_data(); cd2 = alloc_perf_ctx_data(); // { .global = 0, .refcount = 1 };
try_cmpxchg(); // success, // task->perf_ctx_data = cd2 try_cmpxhg(); // fail; old = cd2 refcount_inc_not_zero(&old->refcount); // success // old.refcount = 2 free_perf_ctx_data(cd1);
Then later detach_global_ctx_data() will see the data but it's not marked as global, so it won't call detach_task_ctx_data().
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel perf subsystem contains a race condition vulnerability within the attach_perf_ctx_data function that leads to reference count leaks and potential memory corruption. This issue arises from improper synchronization when handling both global and non-global performance context data structures concurrently. The core of the problem lies in how the system manages shared references between different CPU contexts, specifically when one thread attempts to establish a global context while another simultaneously establishes a non-global context for the same task or event.
In normal operation, the attach_perf_ctx_data function is responsible for allocating and attaching performance context data structures to tasks. When dealing with global contexts, access is protected by the global_ctx_data_rwsem semaphore, ensuring that only one thread can modify the shared global reference count at a time. This mechanism relies on the perf_ctx_data.global field being correctly set during allocation to distinguish between global and non-global instances. However, when this function races with a concurrent call using a non-global flag, the synchronization breaks down because the two operations do not properly coordinate their updates to the task's performance context pointer.
The specific race condition occurs when CPU1 executes attach_task_ctx_data with the global flag set to one while CPU2 simultaneously executes the same function with the global flag set to zero. Both CPUs allocate separate perf_context_data structures, cd1 and cd2 respectively. CPU2 successfully performs a compare-and-swap operation to update task->perf_ctx_data to point to cd2. Meanwhile, CPU1 attempts its own compare-and-swap but fails because CD2 has already updated the pointer. The failure triggers logic that increments the reference count of the old value, which is now cd2 due to CPU2's successful update. Consequently, cd1 remains allocated with a reference count that was never properly managed since it was abandoned by CPU1 without being attached or freed correctly in all code paths.
This race results in a reference count leak because the system fails to set the global field for certain context data structures during concurrent operations. When detach_global_ctx_data is later invoked, it checks whether the associated data is marked as global before calling detach_task_ctx_data. Since the leaked cd1 structure was never properly integrated into the global tracking mechanism due to the race condition, it escapes cleanup procedures. Over time, these unreleased allocations accumulate, leading to memory exhaustion and potential system instability under high concurrency scenarios involving performance monitoring events.
From a vulnerability classification perspective, this issue aligns with CWE-401, which describes missing release of resources after effective usage, commonly known as resource leaks. The lack of proper atomicity in updating shared state structures also relates to CWE-362, concurrent execution using shared resources with improper synchronization. In terms of the MITRE ATT&CK framework, this type of kernel-level race condition could potentially be leveraged for privilege escalation or denial-of-service attacks if an attacker can trigger repeated allocations and races within performance monitoring subsystems.
The operational impact includes gradual memory consumption that may eventually lead to out-of-memory conditions in long-running systems with heavy perf usage patterns. Additionally, the inconsistent state of reference counts increases the risk of use-after-free vulnerabilities if other parts of the kernel attempt to access freed or partially initialized structures. These issues compromise system reliability and security posture by introducing unpredictable behavior in critical subsystems responsible for performance analysis and debugging capabilities.
Mitigation strategies involve ensuring atomic updates to shared context pointers through proper locking mechanisms that cover both allocation and attachment phases without allowing interleaving between global and non-global operations. Developers should implement stricter serialization around the attach_perf_ctx_data function, potentially using finer-grained locks or sequence counters to prevent race conditions during concurrent modifications. Regular code audits focusing on reference counting logic in kernel subsystems can help identify similar patterns before they manifest as exploitable vulnerabilities.