A vulnerability was found in ovirt, allowing a user to consume large amounts of memory or CPU time on the host by uploading a maliciously crafted image. This could lead to denial of service on the host, potentially impacting other users.
See also CVE-2015-5162, essentially the same issue on Openstack.
Discussion: http://lists.nongnu.org/archive/html/qemu-block/2018-07/msg00488.html
Statement: Red Hat Enterprise Virtualization 3 is now in Extended Life Phase of the support and maintenance lifecycle. Red Hat Product Security has rated this issue as having a security impact of Moderate, and it is not currently planned to be addressed in future updates of Red Hat Virtualization 3. For additional information, refer to the Red Hat Virtualization Life Cycle: https://access.redhat.com/support/policy/updates/rhev/
External References: https://gerrit.ovirt.org/#/c/93195/
Acknowledgments: Name: Nir Soffer (Red Hat)
Doran, this was fixed long time ago in vdsm in: commit 6ce96e77be98e7c2bd0daa57294b717b71fa6641 Author: Nir Soffer <nsoffer> AuthorDate: Fri Jul 20 00:10:55 2018 +0300 Commit: Nir Soffer <nsoffer> CommitDate: Wed Aug 8 20:45:05 2018 +0300 hsm: Limit qemu-img resources Turns out qemu image parser is not hardened against malicious input and can be abused to allocate an arbitrary amount of memory and/or dump a lot of information when used with "--output=json". The solution is to limit the resources used by qemu-img when using it with untrusted image. qemuimg.info() has now a new option "trusted_image", set to True by default. Calling with trusted_image=False will limit the CPU time and address space size of the underlying qemu-img command. The new option is used when verifying untrusted images uploaded by users. If "qemu-img info" to run more than 30 seconds or allocate more than 1 GiB, the command will terminate abnormally, failing the verification. Here is an example run with a malicious image from the OpenStack bug: $ /usr/bin/time -f "%MK" qemu-img info --output json afl3.img >/dev/null 1250976K qemu-img tried to allocated 1.25G of memory. When running with prlimit, it will fail with this error: $ prlimit --as=1073741824 --cpu=1 qemu-img info --output json afl3.img qemu-img: Could not open 'afl3.img': Cannot allocate memory See the discussion in qemu-block mailing list: http://lists.nongnu.org/archive/html/qemu-block/2018-07/msg00488.html Original OpenStack bug: http://lists.nongnu.org/archive/html/qemu-block/2018-07/msg00488.html Change-Id: Idc810d1c1eab044353097944d98c3c9f0ea3da6e Signed-off-by: Nir Soffer <nsoffer> $ git describe 6ce96e77be98e7c2bd0daa57294b717b71fa6641 v4.30.0-515-g6ce96e77b Any reason to keep this bug in NEW state?
> Any reason to keep this bug in NEW state? CVE bugs are normally closed by automation when trackers are closed. It seems to have missed this for some reason. The fix for this issue was made available for RHV in https://access.redhat.com/errata/RHEA-2018:2624