Red Hat Bugzilla – Bug 1422656
REJECTED CVE-2017-6000 Qemu: crypto: memory leakage in qcrypto_ivgen_essiv_init
Last modified: 2017-02-17 03:55:22 EST
Quick Emulator(Qemu) built with the Crypto block IV generator - essiv support is vulnerable to a host memory leakage issue. It could occur while initialising the crypto device in 'qcrypto_ivgen_essiv_init'. A guest user/process could use this flaw to leak host memory resulting in DoS. Upstream patch: --------------- -> https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg00295.html Reference: ---------- -> http://www.openwall.com/lists/oss-security/2017/02/16/2
Acknowledgments: Name: Li Qiang (360.cn Inc.)
Created qemu tracking bugs for this issue: Affects: fedora-all [bug 1422657]
(In reply to Prasad J Pandit from comment #0) > Quick Emulator(Qemu) built with the Crypto block IV generator - essiv support > is vulnerable to a host memory leakage issue. It could occur while > initialising > the crypto device in 'qcrypto_ivgen_essiv_init'. > > A guest user/process could use this flaw to leak host memory resulting in > DoS. I don't believe that analysis is correct. qcrypto_ivgen_essiv_init() is called only from qcrypto_ivgen_new(). qcrypto_ivgen_new() is called only from qcrypto_block_qcow_init() or qcrypto_block_luks_open() or qcrypto_block_luks_create(). None of those three methods can be triggered by guest code. They are only triggered in response to a host administrator adding a new virtual disk to QEMU. IOW, you have a leak that only occurs during file open time in the host - it doesn't leak during guest I/O operations.
FYI I intend to close this NOTABUG unless you can show a scenario in which the guest can trigger this leak.
Hello Dan, (In reply to Daniel Berrange from comment #3) > None of those three methods can be triggered by guest code. They are only > triggered in response to a host administrator adding a new virtual disk to > QEMU. > > IOW, you have a leak that only occurs during file open time in the host - it > doesn't leak during guest I/O operations. Ah I see, thank you so much for the details. Will close this as non-issue. Thank you.
Could you also reply to the quoted oss-security mail to report that this is not in fact a vulnerability in QEMU.