On 1/10/20 5:32 PM, Jonathon Jongsma wrote:
We have to assume that the guest agent may be malicious, so we don't want to allow any agent queries to block any other libvirt API. By holding a monitor job and an agent job while we're querying the agent, any other threads will be blocked from using the monitor while the agent is unresponsive. Because libvirt waits forever for an agent response, this makes us vulnerable to a denial of service from a malicious (or simply buggy) guest agent. Most of the patches in the first series were already reviewed and pushed, but a couple remain: the filesystem info functions. The problem with these functions is that the agent functions access the vm definition (owned by the domain). If a monitor job is not held while this is done, the vm definition could change while we are looking up the disk alias, leading to a potentional crash.
Did we ever hear back on a CVE assignment for the first series? And do any of the patches in this series also fall under the CVE umbrella?
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
