Cloudanix VulnDB

CVE-2026-90272

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel sampling feature could accidentally send leftover internal data to programs that asked for certain performance measurements on ARM processors.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Information Disclosure
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The unpatched code passes an uninitialized hw_id field from the BRBE driver to userspace when PERF_SAMPLE_BRANCH_HW_INDEX is requested, exposing whatever stack or heap contents occupy that memory location.

Why it matters to the business

Low-probability exposure of small amounts of kernel memory contents to local processes that can invoke perf; no widespread operational disruption expected given the niche sampling requirement and low exploitability signals.

How an attack unfolds

A local user with perf_event_paranoid access configures a branch-stack sampling event requesting PERF_SAMPLE_BRANCH_HW_INDEX, triggers the BRBE hardware path, and reads the returned sample buffer to obtain whatever data was left in the uninitialized hw_id field.

How to fix it

Update the Linux kernel to a version containing the zero-initialization change for the hw_id field in the arm_pmuv3 BRBE driver; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm the hw_id field is explicitly zeroed in the branch-stack sample path after the patch; re-test sampling with PERF_SAMPLE_BRANCH_HW_INDEX and verify the field contains only zeros.

Typical attack path

  1. Obtain local access on an affected ARMv8 system with perf monitoring enabled
  2. Create a perf_event_attr requesting branch stack sampling and PERF_SAMPLE_BRANCH_HW_INDEX
  3. Enable the event and collect samples via the BRBE driver path
  4. Inspect the hw_id field in returned samples for residual kernel memory contents

How to detect it

No reliable post-exploitation artifacts exist; review perf event creation logs or audit records for unexpected branch-stack sampling requests on ARM systems, but these are normal operations and not distinctive of exploitation.

What your security team should do

  • Prioritize kernel updates on any ARM systems exposing perf to untrusted local users
  • Review perf_event_paranoid settings and restrict branch-stack sampling where feasible
  • Monitor upstream stable and distribution kernel changelogs for the referenced arm_pmuv3 fix

The record

In the Linux kernel, the following vulnerability has been resolved: perf: arm_pmuv3: Zero initialize hw_id branch stack field PERF_SAMPLE_BRANCH_HW_INDEX is supported by BRBE so hw_id is passed to userspace, but it's never set by the BRBE driver. Zero initialize it as it should be according to the docs: * For the architectures whose raw branch records are * already stored in age order, the hw_idx should be 0. It's probably too risky to remove PERF_SAMPLE_BRANCH_HW_INDEX from BRBE now in case anyone is setting it and reading the value, but zero initializing the whole struct also protects against the same issue with new fields that are added in the future.

Affected packages

Ecosystem Package Introduced Fixed