On 01/17/2018 10:13 AM, Michal Privoznik wrote: > On 01/16/2018 06:01 PM, Daniel P. Berrange wrote: >> We read from QEMU until seeing a \r\n pair to indicate a completed reply >> or event. To avoid memory denial-of-service though, we must have a size >> limit on amount of data we buffer. 10 MB is large enough that it ought >> to cope with normal QEMU replies, and small enough that we're not >> consuming unreasonable mem. >> >> > > ACK, although is this really a CVE? Doesn't look that harmful to me. I > mean, owning qemu is not that easy, is it? We treat qemu as untrusted, in case a guest escapes qemu due to some other CVE. If a guest really did cause qemu to emit unbounded QMP text, and it starves libvirtd, then that guest has mounted a denial of service against anything else libvirtd is starved from doing. So yes, in my opinion it is a CVE, even if it is an unlikely case because it won't trigger without a flaw in more than one layer. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
