Description
In the Linux kernel, the following vulnerability has been resolved:

perf/x86/intel: Fix kernel address leakages in LBR stack

Before Arch LBR gained CPL filtering support, a user-only branch stack
could still contain kernel addresses. As a result, kernel branch records
may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is
requested.

For example, on Intel Tiger Lake, the following command can still report
SYSRET/ERET entries with kernel-space from addresses:

$ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \
./perf bench syscall basic --loop 1000 | \
./perf script -i - --fields brstack|tr ' ' '\n'| \
grep -E '0x[89a-f][0-9a-f]{15}'

Total time: 0.000 [sec]

0.219000 usecs/op
4,566,210 ops/sec
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.551 MB - ]
0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/-
0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/-
0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/-
0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/-

The problem is that intel_pmu_lbr_filter() does not fully validate the
privilege level of sampled entries. It filters some mismatches based on
the branch type and the to address, but it does not reject entries whose
from address violates the requested branch privilege filter.

Fix this by extending software filtering to validate both from and to
addresses against br_sel. Any LBR entry contains kernel address does not
match the requested user filter is dropped. This prevents kernel
addresses from appearing in user-only branch stacks.
Published: 2026-09-16
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Information Disclosure
Action: Apply Patch
AI Analysis

Impact

The Linux kernel’s Intel PMU LBR (Last Branch Record) filtering logic was incomplete. A user‑only branch sampling request could still return LBR entries that contain kernel addresses because the from address was not validated against the requested privilege filter. This flaw allows a local user to extract kernel memory addresses through the perf utility.

Affected Systems

Any Linux kernel that has not yet incorporated the commit extending intel_pmu_lbr_filter to validate both from and to addresses is affected. The advisory does not list specific releases, so all kernels lacking this patch are potentially vulnerable.

Risk and Exploitability

The EPSS score is less than 1%, indicating a low probability of observed exploitation. The vulnerability is not cataloged in the CISA KEV database. Attack requires a local user with permission to run perf and enable branch filtering options; thus the likely attack vector is a local user utilizing 'perf record' with branch sampling. Because the exposure is limited to kernel address disclosure and not direct code execution or denial of service, the risk is moderate.

Generated by OpenCVE AI on September 18, 2026 at 08:28 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update to a Linux kernel version that includes the commit extending intel_pmu_lbr_filter to full privilege validation for LBR entries.
  • Set /proc/sys/kernel/perf_event_paranoid to a higher value (e.g., 2 or 3) to restrict perf branch sampling to privileged users only until the patch is applied.
  • Use an alternative profiling tool that does not expose LBR data, or omit branch filtering options when using perf until the kernel is patched.

Generated by OpenCVE AI on September 18, 2026 at 08:28 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4817-1 linux-6.12 security update
Debian DSA Debian DSA DSA-6528-1 linux security update
History

Fri, 18 Sep 2026 08:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-200

Wed, 16 Sep 2026 10:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix kernel address leakages in LBR stack Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \ ./perf bench syscall basic --loop 1000 | \ ./perf script -i - --fields brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks.
Title perf/x86/intel: Fix kernel address leakages in LBR stack
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-16T10:33:00.162Z

Reserved: 2026-09-11T19:38:34.779Z

Link: CVE-2026-89984

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-16T11:17:09.403

Modified: 2026-09-16T11:17:09.403

Link: CVE-2026-89984

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-18T08:30:06Z

Weaknesses
  • CWE-200

    Exposure of Sensitive Information to an Unauthorized Actor