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. References: https://lore.kernel.org/all/20230921160712.99521-1-simon.rowe@nutanix.com/T/ https://lists.nongnu.org/archive/html/qemu-devel/2023-09/msg01011.html
Created qemu tracking bugs for this issue: Affects: fedora-all [bug 2247771]
Unclear why this CVE was created considering we don't officially support nested virtualization unless there's a support exception, see: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_virtualization/creating-nested-virtual-machines_configuring-and-managing-virtualization I left the needinfo to help answer that... Beyond that it's debatable this actually reaches the level of a medium severity. The referenced upstream patch was not accepted and debate has moved on to: https://lore.kernel.org/qemu-devel/20230906130922.142845-1-f.ebner@proxmox.com/T/#u As it was felt to be a more reasonable solution. The update will be placed into a pull request, see: https://lore.kernel.org/qemu-devel/ab6655b0-a6cf-4c19-56d2-e1cb0e6ac72b@linaro.org/
Hi John, > Unclear why this CVE was created considering we don't officially support > nested virtualization unless there's a support exception, see: > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/ > html/configuring_and_managing_virtualization/creating-nested-virtual- > machines_configuring-and-managing-virtualization > > I left the needinfo to help answer that... This issue was originally reported by Simon Rowe (Nutanix) to qemu-security ML. It got stuck for some time and eventually evaluated to be CVE worthy. John Snow (QEMU IDE maintainer) was involved in the discussion. We (ProdSec) care about tracking and reporting all security issues within software that is shipped by Red Hat, even when Tech Preview. This is because we'd want to fix CVEs before moving from Tech Preview to Fully Supported. Obviously Tech Preview has a bearing on RH flaw severity, and we leave fix decisions to Engineering as per their life-cycle policies. > Beyond that it's debatable this actually reaches the level of a medium > severity. Moderate seemed a good compromise between potentially bad impact (bootloader overwrite) and Tech Preview policy. > The referenced upstream patch was not accepted and debate has moved on to: > > https://lore.kernel.org/qemu-devel/20230906130922.142845-1-f.ebner@proxmox. > com/T/#u > > As it was felt to be a more reasonable solution. The update will be placed > into a pull request, see: > > https://lore.kernel.org/qemu-devel/ab6655b0-a6cf-4c19-56d2- > e1cb0e6ac72b/ Thanks for the update.
Statement: Red Hat currently provides the nested virtualization feature as a Technology Preview. Nested virtualization is therefore unsupported for production use. For more information please refer to https://access.redhat.com/solutions/21101 and https://access.redhat.com/support/offerings/techpreview.
FWIW: IDE/SATA is really low on the priority list of things John has time to work. We've been trying to find someone from the community to pick it up for quite a while now - no takers. It's really old technology and the issue reads like a corner case of what anyone could possibly do, hence why I question "medium". Philippe has posted the PR for QEMU, but did not reference the CVE# in the PR https://lore.kernel.org/qemu-devel/20231106110336.358-48-philmd@linaro.org/ https://lore.kernel.org/qemu-devel/20231106110336.358-49-philmd@linaro.org/ These should land in qemu-8.2
Upstream commits: https://gitlab.com/qemu-project/qemu/-/commit/7d7512019fc40c577e2bdd61f114f31a9eb84a8e https://gitlab.com/qemu-project/qemu/-/commit/cc610857bbd3551f4b86ae2299336b5d9aa0db2b
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2024:2135 https://access.redhat.com/errata/RHSA-2024:2135
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2024:2962 https://access.redhat.com/errata/RHSA-2024:2962