CVE-2026-93181 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel/uncore: Fix uncore_box ref/unref ordering
In uncore_event_cpu_online(), uncore_box_ref() was called before uncore_change_context(). uncore_box_ref() gates on box->cpu >= 0, but box->cpu is still -1 at that point because uncore_change_context() has not run yet. As a result, the box is never initialized on the first CPU to come online in a die, leaving it permanently uninitialized in the single-CPU-per-die case.
Thus, box->refcnt is one count below the true value, and in the CPU offline path, the box will be torn down on the second-to-last CPU.
In uncore_event_cpu_offline(), uncore_box_unref() was called after uncore_change_context(), so box->cpu is already -1 when the collector CPU goes offline, which prevents it from tearing down the box.
Fix by swapping the call order in both paths so that uncore_box_{ref,unref}() runs at the point where box->cpu reflects
the correct context.
Move allocate_boxes() out of uncore_box_ref() to enable this reordering.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel contains a critical initialization and lifecycle management flaw within the performance monitoring subsystem for Intel x86 processors, specifically affecting the uncore event handling mechanisms. This vulnerability stems from an incorrect ordering of function calls during CPU online and offline events in the perf/x86/intel/uncore driver. The core issue lies in the sequence where reference counting operations are executed relative to context changes that update internal state variables. Specifically, within the uncore_event_cpu_online() routine, the system invokes uncore_box_ref() before executing uncore_change_context(). This ordering is problematic because uncore_box_ref() relies on the box->cpu variable being set to a valid CPU identifier greater than or equal to zero to properly gate its initialization logic. However, at the moment of this call, box->cpu remains initialized to negative one since the context change has not yet occurred. Consequently, for the first CPU coming online in any given die, particularly in configurations with only one active CPU per die, the uncore box fails to initialize entirely. This results in a permanently uninitialized state that persists throughout the system's uptime, preventing proper performance monitoring capabilities for those specific hardware units.
The operational impact of this initialization failure extends deeply into the reference counting mechanism and subsequent resource teardown processes. Because the initial reference count is not properly incremented due to the skipped initialization path, box->refcnt ends up being one count lower than its true expected value. This discrepancy creates a cascade effect during CPU offline events where the system attempts to manage resources for departing CPUs. In the uncore_event_cpu_offline() function, the current implementation calls uncore_box_unref() after uncore_change_context(). By this point, box->cpu has already been reset to negative one as part of the context teardown process. Since the unref logic also gates on valid CPU identifiers, it fails to execute properly when the collector CPU goes offline. This leads to a situation where the uncore box is either torn down prematurely during the second-to-last CPU's exit or, conversely, not cleaned up correctly depending on the specific race conditions and state interactions. The net result is potential resource leaks, incorrect performance data aggregation, or system instability due to improper handling of hardware monitoring structures.
From a vulnerability classification perspective, this defect aligns with CWE-665 Improper Initialization as it involves failing to properly set initial values for variables that control critical subsystem behavior. Furthermore, the lifecycle management errors relate to CWE-401 Missing Release of Memory after Effective Lifetime and CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization if the incorrect refcounting leads to use-after-free scenarios or double frees in complex multi-core environments. In terms of attack surface and tactical mapping under MITRE ATT&CK, this type of kernel-level logic error can be leveraged for privilege escalation by an attacker who has already achieved local code execution. By manipulating CPU hotplug events or triggering specific performance monitoring contexts, a malicious actor could potentially corrupt memory structures associated with the uncore boxes, leading to arbitrary code execution or denial of service conditions that compromise system integrity and availability.
The resolution involves restructuring the call sequence within both the online and offline event handlers to ensure that reference counting operations occur only after the CPU context has been correctly established or cleared. In the online path, developers must swap the order so that uncore_change_context() executes before uncore_box_ref(), ensuring box->cpu holds a valid value when the reference count is incremented. Similarly, in the offline path, the sequence must be adjusted to handle teardown logic appropriately relative to context changes. Additionally, the fix requires refactoring by moving allocate_boxes() out of uncore_box_ref(). This separation allows for greater flexibility in call ordering and ensures that memory allocation does not depend on state variables that are still being updated during the transition phases. These changes restore correct reference counting semantics, ensuring that resources are allocated when needed and released exactly once upon completion, thereby eliminating the risk of leaks or premature destructions associated with this subsystem.