A bug in QEMU could cause a guest I/O operation otherwise addressed to an arbitrary disk offset to be targeted to offset 0 instead (potentially overwriting the VM's boot code). This could be used, for example, by L2 guests with a virtual disk (vdiskL2) stored on a virtual disk of an L1 (vdiskL1) hypervisor to read and/or write data to LBA 0 of vdiskL1, potentially gaining control of L1 at its next reboot.
Workaround:
The product utilizes a shared resource in a concurrent manner, but it does not correctly synchronize access to the resource.
The product utilizes multiple threads or processes to allow temporary access to a shared resource that can only be exclusive to one process at a time, but it does not properly synchronize these actions, which might cause simultaneous accesses of this resource by multiple threads or processes.
| Link | Tags |
|---|---|
| https://access.redhat.com/errata/RHSA-2024:2135 | vendor advisory |
| https://access.redhat.com/errata/RHSA-2024:2962 | vendor advisory |
| https://access.redhat.com/security/cve/CVE-2023-5088 | vdb entry third party advisory |
| https://bugzilla.redhat.com/show_bug.cgi?id=2247283 | issue tracking patch |
| https://lore.kernel.org/all/20230921160712.99521-1-simon.rowe@nutanix.com/T/ | mailing list patch |
| https://lists.debian.org/debian-lts-announce/2024/03/msg00012.html | |
| https://security.netapp.com/advisory/ntap-20231208-0005/ |