CVE-2026-80602 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/amd/lbr: Fix kernel address leakage
A user-only branch stack can contain branches that originate from the kernel. As a result, kernel addresses are exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. On AMD processors supporting X86_FEATURE_AMD_LBR_V2, perf can still report SYSRET/ERET entries for which the branch-from addresses are in the kernel.
E.g.
$ perf record -e cycles -o - -j any,save_type,u -- \ perf bench syscall basic --loop 1000 | \ perf script -i - -F brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}'
... 0xffffffff81001268/0x717a90a38f1a/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a39157/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a2c628/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a41b60/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a8bef1c30/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a8e4d3c90/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH ...
The reason is that the hardware filter only considers the privilege level applicable to the branch target. Extend software filtering to also validate the branch-from addresses against br_sel, so that any branch record whose branch-from address is in the kernel is dropped when PERF_SAMPLE_BRANCH_USER is requested.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
This vulnerability represents a significant information disclosure flaw within the Linux kernel's performance monitoring subsystem on AMD processors equipped with LBR V2 features. The core issue lies in how hardware-level filtering for Branch Record Stack (LBR) entries interacts with user-space access controls. When an application utilizes the perf interface to record branch instructions, it can specify various sampling types via the br_sel field. Specifically, requesting PERF_SAMPLE_BRANCH_USER is intended to capture only branches originating from or targeting user-mode code, thereby isolating kernel internals from unprivileged processes. However, due to a limitation in the hardware filtering logic on affected AMD processors, the filter primarily evaluates the privilege level of the branch target rather than the source address. Consequently, when execution transitions between user space and kernel space—such as during system calls or interrupts—the Last Branch Record entries may contain addresses from the kernel code segment even though the overall context was initiated by a user-space process. This results in sensitive kernel virtual memory addresses being written into buffers that are subsequently mapped to user space for analysis, effectively bypassing the intended isolation boundaries established by the PERF_SAMPLE_BRANCH_USER flag.
The operational impact of this vulnerability is primarily centered on information leakage and potential security implications related to address layout randomization. By exposing kernel instruction pointers such as those associated with SYSRET or ERET instructions, an attacker could potentially gain insights into the current state of the kernel's memory layout. While modern systems employ Kernel Address Space Layout Randomization (KASLR) to mitigate exploitation techniques that rely on fixed addresses, consistent leakage of these values can aid in defeating KASLR by allowing attackers to correlate leaked pointers with known offsets or symbols within the kernel image. Furthermore, this exposure violates fundamental security principles regarding privilege separation and data confidentiality, as it allows a low-privilege entity to observe high-privilege execution paths. This aligns closely with CWE-200, which classifies such issues under Information Exposure, specifically where sensitive information is accessible to unauthorized actors through improper access control mechanisms in system monitoring tools.
From an offensive security perspective, this flaw can be leveraged within the context of ATT&CK technique T1608, or Step Up from a Local Application, although it more directly relates to reconnaissance activities such as gathering victim identity (T1592) by fingerprinting kernel versions and memory layouts through side-channel-like analysis of branch traces. The vulnerability exploits the trust placed in hardware performance counters to provide accurate profiling data without adequately sanitizing the output for unprivileged consumers. The technical root cause is identified as an incomplete implementation of software filtering logic that fails to validate the source address of each branch record against the selection criteria defined by br_sel. To rectify this, developers have extended the software-side validation process within the perf/x86/amd/lbr subsystem. This fix ensures that every branch entry retrieved from the hardware buffer is checked for its origin address; if a branch originates from kernel space while only user-space branches were requested, the record is explicitly dropped before being exposed to the application.
Mitigation strategies involve applying the upstream Linux kernel patches that implement this additional validation layer. System administrators and users relying on performance profiling tools should ensure their kernels are updated to versions containing this fix. For environments where immediate patching is not feasible, restricting access to perf events via capabilities such as CAP_SYS_ADMIN or utilizing cgroups to limit unprivileged user access to hardware performance counters can reduce the attack surface. Additionally, organizations should audit their use of branch stack sampling features in production profiling tools and consider disabling LBR recording for untrusted users until the patch is deployed. This incident underscores the critical importance of verifying both source and destination contexts when implementing security filters around hardware-assisted debugging and monitoring features, ensuring that privilege boundaries are enforced comprehensively across all dimensions of execution flow data.