Description

When a process calls execve(2) to execute a setuid or setgid image, hwpmc(4) is supposed to detach PMCs owned by unprivileged processes. An inverted check meant that this scenario was not handled properly. An unprivileged local user who has attached PMCs to a process can continue monitoring it after the process executes a setuid or setgid binary, contrary to the intended policy.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-26T05:18:12.080Z",
  "pubdate": "2026-08-26T05:18:12.080Z",
  "executiveSummary": "This vulnerability involves an improper privilege management flaw within the hwpmc(4) subsystem. The issue arises when a process executes a setuid or setgid binary via execve(2).\nUnder security policy, the kernel should automatically detach Performance Monitoring Counters (PMCs) owned by an unprivileged process when it transitions to a higher privilege level through a setuid/setgid execution. Due to an inverted logical check, this detachment process fails to occur.\nThe vulnerability allows an unprivileged local attacker to maintain active monitoring of a process even after it elevates privileges. This results in an information disclosure capability, as the attacker can continue to observe the hardware performance statistics of the elevated process, potentially leaking sensitive information or cryptographic material derived from hardware execution patterns.\nSuccessful exploitation requires local access and the ability to initiate and maintain PMC attachments to a target process prior to the execution of a setuid/setgid image. No remote network exposure is associated with this flaw; however, it represents a significant bypass of the principle of least privilege in kernel-level monitoring.",
  "technicalDetails": "The root cause of this vulnerability is a logic inversion within the kernel's process transition handling code for the hwpmc(4) driver. When the execve(2) system call is invoked, the kernel performs a security check to determine if existing PMC contexts associated with the calling process should be invalidated or detached.\nSpecifically, the hwpmc(4) subsystem is designed to ensure that when a process image is replaced by a setuid/setgid binary, any PMCs that might be leaking information from the elevated process must be cleared. The implementation contained a conditional logic error, treating the intended security check as inverted, thereby effectively skipping the detachment routine for setuid/setgid transitions.\nThe attack flow proceeds as follows: 1) An unprivileged user initiates a PMC session and attaches the PMCs to a target process or the user's own process. 2) The user then triggers an execve(2) syscall to execute a setuid or setgid binary. 3) Because the inverted check fails to trigger the PMC detachment logic, the PMC hardware remains configured and active while the new, higher-privileged process image executes.\nThis allows the attacker to continue reading performance counters that are sensitive to the internal logic and code execution flow of the elevated binary. By analyzing these performance statistics (e.g., cache hits, branch mispredictions, or instruction counts), an attacker can perform side-channel analysis to infer secrets, such as private keys or password hashing operations performed by the elevated process.\nThe vulnerable component is the kernel-level integration of hwpmc(4) within the execve(2) path. Because this occurs within the kernel boundary, the attacker does not require additional elevated permissions to exploit the logic error beyond the local access already granted to use the PMC subsystem. The impact is a breach of security boundaries where hardware-level observations persist across the transition from unprivileged to privileged execution contexts, violating the intended design of the kernel security model."
}