CVE-2021-47390
- Source
- https://nvd.nist.gov/vuln/detail/CVE-2021-47390
- Import Source
- https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2021-47390.json
- JSON Data
- https://api.osv.dev/v1/vulns/CVE-2021-47390
- Related
- Published
- 2024-05-21T15:15:24Z
- Modified
- 2024-09-18T03:17:26.847264Z
- Summary
- [none]
- Details
-
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Fix stack-out-of-bounds memory access from ioapicwriteindirect()
KASAN reports the following issue:
BUG: KASAN: stack-out-of-bounds in kvmmakevcpusrequestmask+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 DAYTONAX/DAYTONAX, BIOS RYM0081C 07/13/2020 Call Trace: dumpstack+0xa5/0xe6 printaddressdescription.constprop.0+0x18/0x130 ? kvmmakevcpusrequestmask+0x174/0x440 [kvm] _kasanreport.cold+0x7f/0x114 ? kvmmakevcpusrequestmask+0x174/0x440 [kvm] kasanreport+0x38/0x50 kasancheckrange+0xf5/0x1d0 kvmmakevcpusrequestmask+0x174/0x440 [kvm] kvmmakescanioapicrequestmask+0x84/0xc0 [kvm] ? kvmarchexit+0x110/0x110 [kvm] ? schedclock+0x5/0x10 ioapicwriteindirect+0x59f/0x9e0 [kvm] ? staticobj+0xc0/0xc0 ? _lockacquired+0x1d2/0x8c0 ? kvmioapiceoiinject_work+0x120/0x120 [kvm]
The problem appears to be that 'vcpubitmap' is allocated as a single long on stack and it should really be KVMMAXVCPUS long. We also seem to clear the lower 16 bits of it with bitmapzero() for no particular reason (my guess would be that 'bitmap' and 'vcpubitmap' variables in kvmbitmapordest_vcpus() caused the confusion: while the later is indeed 16-bit long, the later should accommodate all possible vCPUs).
- References
Affected packages
Debian:11 / linux
Package
- Name
- linux
- Purl
- pkg:deb/debian/linux?arch=source
Debian:12 / linux
Package
- Name
- linux
- Purl
- pkg:deb/debian/linux?arch=source
Debian:13 / linux
Package
- Name
- linux
- Purl
- pkg:deb/debian/linux?arch=source