CVE-2026-80670 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
perf tools: Use perf_env__get_cpu_topology() in machine__resolve()
machine__resolve() accesses env->cpu[al->cpu].socket_id after checking
al->cpu >= 0 and env->cpu != NULL, but without validating al->cpu against env->nr_cpus_avail. Since al->cpu comes from the untrusted perf.data sample, a crafted file with a large CPU index causes an out-of-bounds heap read.
Use perf_env__get_cpu_topology() which validates both NULL and bounds. Also bounds-check al->cpu before the cast to struct perf_cpu (int16_t): without this, values like 65536 silently truncate to 0, bypassing the accessor's internal check and returning CPU 0's topology.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/28/2026
The Linux kernel’s performance analysis tools contain a critical memory safety vulnerability within the machine resolution logic that processes profiling data samples. This flaw specifically resides in the interaction between the perf tooling infrastructure and the underlying hardware topology information structures. The function responsible for resolving CPU context, known as machine__resolve(), is designed to map logical processor identifiers from captured performance events to their corresponding physical or virtual hardware attributes. During this process, the code performs preliminary checks to ensure that the provided CPU identifier is non-negative and that the global environment structure containing CPU topology data exists. However, these safeguards are insufficient because they fail to verify whether the specified CPU index falls within the valid range of available CPUs recorded in the system profile. This oversight creates a scenario where an attacker can exploit untrusted input data to trigger out-of-bounds memory access operations.
The technical root cause is an improper validation of array bounds when accessing the cpu topology array. The variable al->cpu, which represents the logical CPU identifier extracted from a perf.data sample file, originates from external sources and is therefore considered untrusted input. While the code checks if this value is greater than or equal to zero and confirms that the environment pointer is not null, it neglects to compare the index against env->nr_cpus_avail, which denotes the total number of CPUs available in the sampled system. Consequently, when a crafted perf.data file contains a CPU identifier with an excessively large integer value, the subsequent array access operation reads memory locations beyond the allocated heap buffer for cpu topology structures. This constitutes an out-of-bounds read vulnerability that can lead to information disclosure or potentially destabilize the analysis tool by exposing sensitive kernel memory contents adjacent to the intended data structure.
Furthermore, a secondary logical flaw exacerbates this risk through integer truncation issues during type casting operations. Before accessing the CPU topology, the code casts the al->cpu value to a signed 16-bit integer type, struct perf_cpu. This conversion introduces a silent boundary bypass mechanism because large unsigned values can wrap around or truncate into small positive integers due to overflow behavior inherent in fixed-width integer types. For instance, an input value of sixty-five thousand five hundred thirty-six would silently convert to zero after truncation. This truncated value then passes the internal bounds check within the accessor function, effectively allowing access to CPU zero’s topology data even when the original intent was to reference a non-existent or high-numbered processor core. This bypass undermines the protective measures intended by the perf_env__get_cpu_topology() helper function, which is designed to perform comprehensive validation of both null pointers and array bounds before returning relevant hardware information.
The operational impact of this vulnerability extends beyond simple memory corruption risks in user-space tooling. Since performance analysis tools are often executed with elevated privileges or used as part of automated security auditing pipelines, an attacker who can supply malicious perf.data files could leverage this flaw to read arbitrary kernel heap memory. This capability facilitates unauthorized information disclosure, potentially revealing cryptographic keys, process credentials, or other sensitive data structures residing in adjacent memory regions. In more complex attack scenarios involving exploitation chains, such out-of-bounds reads might serve as a primitive for further privilege escalation attacks if combined with additional vulnerabilities that allow control over execution flow based on the leaked memory contents. The vulnerability highlights the dangers of trusting external profiling data without rigorous sanitization and validation procedures at every stage of processing.
To mitigate this risk, developers have implemented a fix that mandates the use of perf_env__get_cpu_topology() for all CPU topology lookups within machine resolution routines. This helper function encapsulates robust defensive programming practices by explicitly checking for null pointers and verifying that the requested CPU index is strictly less than the number of available CPUs in the environment structure. Additionally, the patch introduces explicit bounds checking on al->cpu prior to any type casting operations. By validating the range of the input value before it undergoes conversion to a smaller integer width, the system prevents silent truncation attacks that could otherwise bypass internal validation logic. This approach ensures that only legitimate CPU identifiers within the known hardware configuration are processed, thereby eliminating both out-of-bounds reads and logical bypass vulnerabilities associated with improper type conversions.
From an industry standards perspective, this vulnerability aligns closely with Common Weakness Enumeration category CWE-125, which describes Out-of-Bounds Read scenarios where software reads data past the end or before the beginning of a buffer. The failure to validate input against array limits is a classic example of insufficient boundary checks that lead to memory safety violations. Additionally, the exploitation vector relates to ATT&CK technique T1083, File and Directory Discovery, as attackers may use crafted performance files to probe system structure and gather intelligence about running processes or hardware configurations through side-channel effects of successful versus failed reads. The remediation strategy reinforces best practices for secure coding by emphasizing defense-in-depth principles where multiple layers of validation are applied to untrusted inputs before they interact with sensitive memory structures, ensuring that both syntactic correctness and semantic validity are enforced throughout the data processing pipeline.