fkie_cve-2021-47390
Vulnerability from fkie_nvd
Published
2024-05-21 15:15
Modified
2024-12-30 20:01
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Fix stack-out-of-bounds memory access from ioapic_write_indirect()
KASAN reports the following issue:
BUG: KASAN: stack-out-of-bounds in kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
Read of size 8 at addr ffffc9001364f638 by task qemu-kvm/4798
CPU: 0 PID: 4798 Comm: qemu-kvm Tainted: G X --------- ---
Hardware name: AMD Corporation DAYTONA_X/DAYTONA_X, BIOS RYM0081C 07/13/2020
Call Trace:
dump_stack+0xa5/0xe6
print_address_description.constprop.0+0x18/0x130
? kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
__kasan_report.cold+0x7f/0x114
? kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
kasan_report+0x38/0x50
kasan_check_range+0xf5/0x1d0
kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
kvm_make_scan_ioapic_request_mask+0x84/0xc0 [kvm]
? kvm_arch_exit+0x110/0x110 [kvm]
? sched_clock+0x5/0x10
ioapic_write_indirect+0x59f/0x9e0 [kvm]
? static_obj+0xc0/0xc0
? __lock_acquired+0x1d2/0x8c0
? kvm_ioapic_eoi_inject_work+0x120/0x120 [kvm]
The problem appears to be that 'vcpu_bitmap' is allocated as a single long
on stack and it should really be KVM_MAX_VCPUS long. We also seem to clear
the lower 16 bits of it with bitmap_zero() for no particular reason (my
guess would be that 'bitmap' and 'vcpu_bitmap' variables in
kvm_bitmap_or_dest_vcpus() caused the confusion: while the later is indeed
16-bit long, the later should accommodate all possible vCPUs).
References
Impacted products
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 5.15 | |
| linux | linux_kernel | 5.15 | |
| linux | linux_kernel | 5.15 |
{
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "60C740E4-6C54-40CD-A914-2232D8FC781D",
"versionEndExcluding": "5.10.71",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "1A437B0D-8305-4C72-B691-D26986A126CF",
"versionEndExcluding": "5.14.10",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:5.15:rc1:*:*:*:*:*:*",
"matchCriteriaId": "E46C74C6-B76B-4C94-A6A4-FD2FFF62D644",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:5.15:rc2:*:*:*:*:*:*",
"matchCriteriaId": "60134C3A-06E4-48C1-B04F-2903732A4E56",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:5.15:rc3:*:*:*:*:*:*",
"matchCriteriaId": "0460DA88-8FE1-46A2-9DDA-1F1ABA552E71",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Fix stack-out-of-bounds memory access from ioapic_write_indirect()\n\nKASAN reports the following issue:\n\n BUG: KASAN: stack-out-of-bounds in kvm_make_vcpus_request_mask+0x174/0x440 [kvm]\n Read of size 8 at addr ffffc9001364f638 by task qemu-kvm/4798\n\n CPU: 0 PID: 4798 Comm: qemu-kvm Tainted: G X --------- ---\n Hardware name: AMD Corporation DAYTONA_X/DAYTONA_X, BIOS RYM0081C 07/13/2020\n Call Trace:\n dump_stack+0xa5/0xe6\n print_address_description.constprop.0+0x18/0x130\n ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm]\n __kasan_report.cold+0x7f/0x114\n ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm]\n kasan_report+0x38/0x50\n kasan_check_range+0xf5/0x1d0\n kvm_make_vcpus_request_mask+0x174/0x440 [kvm]\n kvm_make_scan_ioapic_request_mask+0x84/0xc0 [kvm]\n ? kvm_arch_exit+0x110/0x110 [kvm]\n ? sched_clock+0x5/0x10\n ioapic_write_indirect+0x59f/0x9e0 [kvm]\n ? static_obj+0xc0/0xc0\n ? __lock_acquired+0x1d2/0x8c0\n ? kvm_ioapic_eoi_inject_work+0x120/0x120 [kvm]\n\nThe problem appears to be that \u0027vcpu_bitmap\u0027 is allocated as a single long\non stack and it should really be KVM_MAX_VCPUS long. We also seem to clear\nthe lower 16 bits of it with bitmap_zero() for no particular reason (my\nguess would be that \u0027bitmap\u0027 and \u0027vcpu_bitmap\u0027 variables in\nkvm_bitmap_or_dest_vcpus() caused the confusion: while the later is indeed\n16-bit long, the later should accommodate all possible vCPUs)."
},
{
"lang": "es",
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: KVM: x86: corrige el acceso a la memoria de pila fuera de los l\u00edmites desde ioapic_write_indirect() KASAN informa el siguiente problema: BUG: KASAN: pila fuera de los l\u00edmites en kvm_make_vcpus_request_mask+ 0x174/0x440 [kvm] Lectura de tama\u00f1o 8 en la direcci\u00f3n ffffc9001364f638 por tarea qemu-kvm/4798 CPU: 0 PID: 4798 Comm: qemu-kvm Contaminado: GX --------- --- Nombre de hardware: AMD Corporaci\u00f3n DAYTONA_X/DAYTONA_X, BIOS RYM0081C 13/07/2020 Seguimiento de llamadas: dump_stack+0xa5/0xe6 print_address_description.constprop.0+0x18/0x130 ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm] __kasan_report.cold+0x7f/0x114 ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm] kasan_report+0x38/0x50 kasan_check_range+0xf5/0x1d0 kvm_make_vcpus_request_mask+0x174/0x440 [kvm] 0 [kvm] ? kvm_arch_exit+0x110/0x110 [kvm] ? sched_clock+0x5/0x10 ioapic_write_indirect+0x59f/0x9e0 [kvm] ? static_obj+0xc0/0xc0? __lock_acquired+0x1d2/0x8c0? kvm_ioapic_eoi_inject_work+0x120/0x120 [kvm] El problema parece ser que \u0027vcpu_bitmap\u0027 est\u00e1 asignado como un \u00fanico largo en la pila y en realidad deber\u00eda ser KVM_MAX_VCPUS largo. Tambi\u00e9n parece que borramos los 16 bits inferiores con bitmap_zero() sin ning\u00fan motivo en particular (supongo que las variables \u0027bitmap\u0027 y \u0027vcpu_bitmap\u0027 en kvm_bitmap_or_dest_vcpus() causaron la confusi\u00f3n: mientras que la \u00faltima tiene 16 bits de longitud , este \u00faltimo deber\u00eda acomodar todas las vCPU posibles)."
}
],
"id": "CVE-2021-47390",
"lastModified": "2024-12-30T20:01:12.947",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.1,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.2,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2024-05-21T15:15:24.397",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2f9b68f57c6278c322793a06063181deded0ad69"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/99a9e9b80f19fc63be005a33d76211dd23114792"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/bebabb76ad9acca8858e0371e102fb60d708e25b"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2f9b68f57c6278c322793a06063181deded0ad69"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/99a9e9b80f19fc63be005a33d76211dd23114792"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/bebabb76ad9acca8858e0371e102fb60d708e25b"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-125"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…