CVE-2023-52476

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