mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2025-01-20 03:25:18 +00:00
07fdce4fd3
It is possible to deadlock libvirt by having a domain with XML longer than PIPE_BUF, and by writing a hook script that closes stdin early. This is because libvirt was keeping a copy of the child's stdin read fd open, which means the write fd in the parent will never see EPIPE (remember, libvirt should always be run with SIGPIPE ignored, so we should never get a SIGPIPE signal). Since there is no error, libvirt blocks waiting for a write to complete, even though the only reader is also libvirt. The solution is to ensure that only the child can act as a reader before the parent does any writes; and then dealing with the fallout of dealing with EPIPE. Thankfully, this is not a security hole - since the only way to trigger the deadlock is to install a custom hook script, anyone that already has privileges to install a hook script already has privileges to do any number of other equally disruptive things to libvirt; it would only be a security hole if an unprivileged user could install a hook script to DoS a privileged user. * src/util/command.c (virCommandRun): Close parent's copy of child read fd earlier. (virCommandProcessIO): Don't let EPIPE be fatal; the child may be done parsing input. * tests/commandhelper.c (main): Set up a SIGPIPE situation. * tests/commandtest.c (test20): Trigger it. * tests/commanddata/test20.log: New file. (cherry picked from commit 858c2476d9dccf630ad5b7f4d8e0e61e9295c2b6)
LibVirt : simple API for virtualization
Libvirt is a C toolkit to interact with the virtualization capabilities
of recent versions of Linux (and other OSes). It is free software
available under the GNU Lesser General Public License. Virtualization of
the Linux Operating System means the ability to run multiple instances of
Operating Systems concurrently on a single hardware system where the basic
resources are driven by a Linux instance. The library aim at providing
long term stable C API initially for the Xen paravirtualization but
should be able to integrate other virtualization mechanisms if needed.
Daniel Veillard <veillard@redhat.com>