Linux Kernel up to 5.17.2 xen_hvm_init_time_ops allocation of resources

| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 5.3 | $0-$5k | 0.00 |
Summary
A vulnerability marked as problematic has been reported in Linux Kernel up to 5.17.2. The impacted element is the function xen_hvm_init_time_ops. Performing a manipulation results in allocation of resources.
This vulnerability is known as CVE-2022-49101. No exploit is available.
It is suggested to upgrade the affected component.
Details
A vulnerability classified as problematic has been found in Linux Kernel up to 5.17.2. This affects the function xen_hvm_init_time_ops. The manipulation with an unknown input leads to a allocation of resources vulnerability. CWE is classifying the issue as CWE-770. The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor. The impact remains unknown. The summary by CVE is:
In the Linux kernel, the following vulnerability has been resolved: xen: delay xen_hvm_init_time_ops() if kdump is boot on vcpu>=32 The sched_clock() can be used very early since commit 857baa87b642 ("sched/clock: Enable sched clock early"). In addition, with commit 38669ba205d1 ("x86/xen/time: Output xen sched_clock time from 0"), kdump kernel in Xen HVM guest may panic at very early stage when accessing &__this_cpu_read(xen_vcpu)->time as in below: setup_arch() -> init_hypervisor_platform() -> x86_init.hyper.init_platform = xen_hvm_guest_init() -> xen_hvm_init_time_ops() -> xen_clocksource_read() -> src = &__this_cpu_read(xen_vcpu)->time; This is because Xen HVM supports at most MAX_VIRT_CPUS=32 'vcpu_info' embedded inside 'shared_info' during early stage until xen_vcpu_setup() is used to allocate/relocate 'vcpu_info' for boot cpu at arbitrary address. However, when Xen HVM guest panic on vcpu >= 32, since xen_vcpu_info_reset(0) would set per_cpu(xen_vcpu, cpu) = NULL when vcpu >= 32, xen_clocksource_read() on vcpu >= 32 would panic. This patch calls xen_hvm_init_time_ops() again later in xen_hvm_smp_prepare_boot_cpu() after the 'vcpu_info' for boot vcpu is registered when the boot vcpu is >= 32. This issue can be reproduced on purpose via below command at the guest side when kdump/kexec is enabled: "taskset -c 33 echo c > /proc/sysrq-trigger" The bugfix for PVM is not implemented due to the lack of testing environment. [boris: xen_hvm_init_time_ops() returns on errors instead of jumping to end]
It is possible to read the advisory at git.kernel.org. This vulnerability is uniquely identified as CVE-2022-49101 since 02/26/2025. Technical details of the vulnerability are known, but there is no available exploit.
Upgrading to version 4.19.238, 5.4.189, 5.10.111, 5.15.34, 5.16.20 or 5.17.3 eliminates this vulnerability. Applying the patch 0848767dee78c00c5646eef9b3201ee14ce68563/8a7462b5211cd5b74b8815034d038e28cbd96d52/a2a0e04f6478e8c1038db64717f3fafd55de1420/5c0750cad73350e1c504eb91a94093a79f6f6296/be63f365f454e39d09c41bbd21ea72b5244160b5/b6f6b353d6c765b83c9e5e518a44ca1ae40fe227/eed05744322da07dd7e419432dcedf3c2e017179 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Product
Type
Vendor
Name
Version
- 4.19.237
- 5.4.188
- 5.10.110
- 5.15.0
- 5.15.1
- 5.15.2
- 5.15.3
- 5.15.4
- 5.15.5
- 5.15.6
- 5.15.7
- 5.15.8
- 5.15.9
- 5.15.10
- 5.15.11
- 5.15.12
- 5.15.13
- 5.15.14
- 5.15.15
- 5.15.16
- 5.15.17
- 5.15.18
- 5.15.19
- 5.15.20
- 5.15.21
- 5.15.22
- 5.15.23
- 5.15.24
- 5.15.25
- 5.15.26
- 5.15.27
- 5.15.28
- 5.15.29
- 5.15.30
- 5.15.31
- 5.15.32
- 5.15.33
- 5.16.0
- 5.16.1
- 5.16.2
- 5.16.3
- 5.16.4
- 5.16.5
- 5.16.6
- 5.16.7
- 5.16.8
- 5.16.9
- 5.16.10
- 5.16.11
- 5.16.12
- 5.16.13
- 5.16.14
- 5.16.15
- 5.16.16
- 5.16.17
- 5.16.18
- 5.16.19
- 5.17.0
- 5.17.1
- 5.17.2
License
Website
- Vendor: https://www.kernel.org/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔍VulDB Reliability: 🔍
CVSSv3
VulDB Meta Base Score: 5.5VulDB Meta Temp Score: 5.3
VulDB Base Score: 5.5
VulDB Temp Score: 5.3
VulDB Vector: 🔍
VulDB Reliability: 🔍
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vector | Complexity | Authentication | Confidentiality | Integrity | Availability |
|---|---|---|---|---|---|
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
VulDB Base Score: 🔍
VulDB Temp Score: 🔍
VulDB Reliability: 🔍
Exploiting
Class: Allocation of resourcesCWE: CWE-770 / CWE-400 / CWE-404
CAPEC: 🔍
ATT&CK: 🔍
Physical: No
Local: No
Remote: Partially
Availability: 🔍
Status: Not defined
Price Prediction: 🔍
Current Price Estimation: 🔍
| 0-Day | Unlock | Unlock | Unlock | Unlock |
|---|---|---|---|---|
| Today | Unlock | Unlock | Unlock | Unlock |
Threat Intelligence
Interest: 🔍Active Actors: 🔍
Active APT Groups: 🔍
Countermeasures
Recommended: UpgradeStatus: 🔍
0-Day Time: 🔍
Upgrade: Kernel 4.19.238/5.4.189/5.10.111/5.15.34/5.16.20/5.17.3
Patch: 0848767dee78c00c5646eef9b3201ee14ce68563/8a7462b5211cd5b74b8815034d038e28cbd96d52/a2a0e04f6478e8c1038db64717f3fafd55de1420/5c0750cad73350e1c504eb91a94093a79f6f6296/be63f365f454e39d09c41bbd21ea72b5244160b5/b6f6b353d6c765b83c9e5e518a44ca1ae40fe227/eed05744322da07dd7e419432dcedf3c2e017179
Timeline
02/26/2025 🔍02/26/2025 🔍
02/26/2025 🔍
02/26/2025 🔍
Sources
Vendor: kernel.orgAdvisory: git.kernel.org
Status: Confirmed
CVE: CVE-2022-49101 (🔍)
GCVE (CVE): GCVE-0-2022-49101
GCVE (VulDB): GCVE-100-297315
Entry
Created: 02/26/2025 11:11Changes: 02/26/2025 11:11 (57)
Complete: 🔍
Cache ID: 216::103
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
No comments yet. Languages: en.
Please log in to comment.