LiveActive security incident?Get immediate response
CVE Record

CVE-2023-52476: perf/x86/lbr: Filter vsyscall addresses

In the Linux kernel, the following vulnerability has been resolved: perf/x86/lbr: Filter vsyscall addresses We found that a panic can occur when a vsyscall is made while LBR sampling is active. If the vsyscall is interrupted (NMI) for perf sampling, this call sequence can occur (most recent at top): __insn_get_emulate_prefix() insn_get_emulate_prefix() insn_get_prefixes() insn_get_opcode() decode_branch_type() get_branch_type() intel_pmu_lbr_filter() intel_pmu_handle_irq() perf_event_nmi_handler() Within __insn_get_emulate_prefix() at frame 0, a macro is called: peek_nbyte_next(insn_byte_t, insn, i) Within this macro, this dereference occurs: (insn)->next_byte Inspecting registers at this point, the value of the next_byte field is the address of the vsyscall made, for example the location of the vsyscall version of gettimeofday() at 0xffffffffff600000. The access to an address in the vsyscall region will trigger an oops due to an unhandled page fault. To fix the bug, filtering for vsyscalls can be done when determining the branch type. This patch will return a "none" branch if a kernel address if found to lie in the vsyscall region.

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysismoderate

Security readout for executives and security teams

Plain-English summary

This Linux kernel bug can crash a system when performance monitoring with Last Branch Record sampling overlaps with a legacy vsyscall. The available sources describe a kernel panic, not data theft or code execution. Business urgency depends on whether affected x86 kernels are used where perf sampling is enabled.

Executive priority

Treat as a targeted availability risk, not a confirmed widespread emergency. Patch through normal kernel maintenance, with higher priority for monitored, performance-sensitive, or multi-tenant Linux systems using affected kernels.

Technical view

In perf/x86 LBR filtering, branch decoding can dereference a vsyscall-region address during NMI perf sampling. That access causes an unhandled page fault and oops. The resolved change filters vsyscall addresses during branch type determination and returns no branch for that region.

Likely exposure

Exposure is most likely on x86 Linux systems running affected kernel versions where perf LBR sampling is active and vsyscalls can occur. The source data does not define affected distributions, configurations, or cloud images.

Exploitation context

The source bundle marks KEV as false and provides no evidence of active exploitation. It describes a crash condition from a specific kernel/perf interaction. Remote exploitability, required privileges, and practical triggerability are not established in the provided evidence.

Researcher notes

Evidence supports a kernel panic from dereferencing vsyscall-region addresses during perf LBR branch decoding. The provided record lacks CVSS, CWE mapping, distro impact, exploit reports, and precise privilege requirements, so validation should stay source-bound.

Mitigation direction

  • Update to a kernel containing the stable vsyscall filtering fix.
  • Check Linux distribution advisories for the fixed kernel package.
  • Prioritize systems that use perf or performance profiling in production.
  • Review vendor guidance before relying on configuration workarounds.
  • Avoid direct deployment shortcuts; follow normal kernel change controls.

Validation and detection

  • Inventory Linux kernel versions across x86 fleets.
  • Confirm whether deployed kernels include the listed stable commits.
  • Identify production systems using perf LBR sampling or profiling.
  • Review kernel logs for oops or panic traces involving perf LBR filtering.
  • Track distribution advisories against CVE-2023-52476.
Prepared
Confidence
medium
Sources
6

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2023-52476 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
0Timeline events
0ADP providers
5Source links

CVSS and timeline data

No CVSS vectors or timeline events were available in the normalized CVE source material.

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux808b64565b028bd072c985624d5cbe4b6f5a5a35, 808b64565b028bd072c985624d5cbe4b6f5a5a35, 808b64565b028bd072c985624d5cbe4b6f5a5a35unaffected
LinuxLinux5.16, 0, 6.1.59, 6.5.8, 6.6affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.