You are viewing this page in an unauthorized frame window.
This is a potential security issue, you are being redirected to
https://nvd.nist.gov
An official website of the United States government
Official websites use .gov
A .gov website belongs to an official government organization in the United States.
Secure .gov websites use HTTPS
A lock () or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.
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.
Metrics
NVD enrichment efforts reference publicly available information to associate
vector strings. CVSS information contributed by other sources is also
displayed.
By selecting these links, you will be leaving NIST webspace.
We have provided these links to other web sites because they
may have information that would be of interest to you. No
inferences should be drawn on account of other sites being
referenced, or not, from this page. There may be other web
sites that are more appropriate for your purpose. NIST does
not necessarily endorse the views expressed, or concur with
the facts presented on these sites. Further, NIST does not
endorse any commercial products that may be mentioned on
these sites. Please address comments about this page to [email protected].
OR
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions up to (excluding) 5.15.137
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.16 up to (excluding) 6.1.59
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.2 up to (excluding) 6.5.8
*cpe:2.3:o:linux:linux_kernel:6.6:rc1:*:*:*:*:*:*
*cpe:2.3:o:linux:linux_kernel:6.6:rc2:*:*:*:*:*:*
*cpe:2.3:o:linux:linux_kernel:6.6:rc3:*:*:*:*:*:*
*cpe:2.3:o:linux:linux_kernel:6.6:rc4:*:*:*:*:*:*
*cpe:2.3:o:linux:linux_kernel:6.6:rc5:*:*:*:*:*:*
Changed
Reference Type
https://git.kernel.org/stable/c/3863989497652488a50f00e96de4331e5efabc6c No Types Assigned
New CVE Received from kernel.org2/29/2024 1:15:45 AM
Action
Type
Old Value
New Value
Added
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.
Added
Reference
Linux https://git.kernel.org/stable/c/3863989497652488a50f00e96de4331e5efabc6c [No types assigned]
Added
Reference
Linux https://git.kernel.org/stable/c/403d201d1fd144cb249836dafb222f6375871c6c [No types assigned]
Added
Reference
Linux https://git.kernel.org/stable/c/e53899771a02f798d436655efbd9d4b46c0f9265 [No types assigned]
Added
Reference
Linux https://git.kernel.org/stable/c/f71edacbd4f99c0e12fe4a4007ab4d687d0688db [No types assigned]
Quick Info
CVE Dictionary Entry: CVE-2023-52476 NVD
Published Date: 02/29/2024 NVD
Last Modified: 01/10/2025
Source: kernel.org