CVE-2023-52476

perf/x86/lbr: Filter vsyscall addresses

MEDIUM
5.5
CVSS Score
Published: February 29, 2024 at 05:43 AM UTC
Updated: June 17, 2026 at 06:42 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
MEDIUM5.5
Exploit prediction
EPSS 0.2%
SSVC
No known exploit

Description

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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

v < 5.15.1375.16 ≤ v < 6.1.595.16 ≤ v < 6.5.85.16 ≤ v < 6.66.2 ≤ v < 6.5.86.6 rc16.6 rc26.6 rc36.6 rc46.6 rc5808b64565b028bd072c985624d5cbe4b6f5a5a35
Vendor states this is fixed in 3863989497652488a50f00e96de4331e5efabc6c (fixed)
Vendor states this is fixed in e53899771a02f798d436655efbd9d4b46c0f9265 (fixed)
Vendor states this is fixed in f71edacbd4f99c0e12fe4a4007ab4d687d0688db (fixed)
Affected range stops below 5.15.137, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 5.16 (unaffected)
Vendor states this is fixed in 6.1.59 (unaffected)
Vendor states this is fixed in 6.5.8 (unaffected)
Vendor states this is fixed in 6.6 (unaffected)

References (4)

Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/3863989497652488a50f00e96de4331e5efabc6c
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/403d201d1fd144cb249836dafb222f6375871c6c
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/e53899771a02f798d436655efbd9d4b46c0f9265
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/f71edacbd4f99c0e12fe4a4007ab4d687d0688db

SSVC — Action Prioritization

SSVCNo known exploitNot automatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

Attack Vector
LOCAL
Complexity
LOW
Privileges
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
NONE
Integrity
NONE
Availability
HIGH
Vector?

Quick Info

StatusMODIFIED
CWE
NVD-CWE-noinfo

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card