CVE-2026-93181: perf/x86/intel/uncore: Fix uncore_box ref/unref ordering
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel/uncore: Fix uncorebox ref/unref ordering
In uncoreeventcpuonline(), uncoreboxref() was called before uncorechangecontext(). uncoreboxref() gates on box->cpu >= 0, but box->cpu is still -1 at that point because uncorechangecontext() 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 uncoreeventcpuoffline(), uncoreboxunref() was called after uncorechangecontext(), 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 uncorebox{ref,unref}() runs at the point where box->cpu reflects the correct context.
Move allocateboxes() out of uncoreboxref() to enable this reordering.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
perf/x86/intel/uncoreto a version that resolves this vulnerability.Patch perf/x86/intel/uncore: Fix uncore_box ref/unref ordering
Event History
Frequently Asked Questions
Which systems are most likely to be affected by this issue?
Systems using the Linux kernel's Intel x86 uncore performance-monitoring support are relevant. The failure is specifically described for a die with only one CPU coming online, where the uncore box can remain permanently uninitialized.
What operational condition triggers the incorrect reference handling?
The issue occurs during CPU online and offline handling when the uncore box reference or unreference operation runs while box->cpu does not yet, or no longer, reflect the correct collector CPU context. This can cause initialization to be skipped or teardown to occur at the wrong time.
What is the practical impact during CPU offlining?
Because the reference count can be one below its true value, the uncore box may be torn down when the second-to-last CPU goes offline rather than when the final relevant CPU goes offline. Conversely, when the collector CPU goes offline, teardown can be skipped because box->cpu has already been set to -1.