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