CVE-2023-52476

What it actually does

The flaw permits a local process to trigger an unhandled page fault and kernel oops by executing a vsyscall while LBR sampling is active; the perf LBR filter path dereferences an address inside the vsyscall region (e.g., 0xffffffffff600000) without prior range checks during branch-type decoding.

Why it matters to the business

Unexpected system crashes and loss of availability on Linux hosts that run perf with LBR sampling enabled, disrupting workloads that rely on continuous performance monitoring or that invoke vsyscall-based library functions.

How an attack unfolds

An attacker with local access starts a perf session configured for LBR sampling, forces a vsyscall (such as the gettimeofday implementation at the fixed vsyscall address), and arranges for an NMI to occur during the vsyscall; the resulting call chain reaches __insn_get_emulate_prefix which dereferences the vsyscall address and triggers the fatal page fault.

How to fix it

Upgrade the Linux kernel to a version containing commit 3863989497652488a50f00e96de4331e5efabc6c (or the corresponding stable backport) which adds vsyscall-region checks inside get_branch_type before any memory access.

How to confirm the fix worked

Confirm the fix by inspecting the intel_pmu_lbr_filter or get_branch_type functions for the new vsyscall address range test; alternatively, run a reproducer that exercises vsyscalls under LBR sampling and verify the kernel no longer panics.

Typical attack path

1. Start perf record or similar with LBR branch sampling enabled
2. Trigger a vsyscall (e.g., via libc time functions)
3. Generate an NMI while the vsyscall is executing
4. Reach intel_pmu_lbr_filter and get_branch_type without vsyscall filtering
5. Dereference vsyscall-region address inside peek_nbyte_next causing oops

How to detect it

Search kernel logs and dmesg for oops or panic messages containing __insn_get_emulate_prefix, insn_get_emulate_prefix, get_branch_type, or references to the vsyscall address range 0xffffffffff600000 while perf_event_nmi_handler appears in the stack trace.

What your security team should do

• Apply the referenced kernel commit or distribution update that contains the vsyscall filter as soon as possible
• Temporarily disable LBR sampling in perf configurations on unpatched systems
• Add kernel oops monitoring for perf/LBR symbols to detect attempted exploitation