networkCreateInterfacePool was a bit loose in its error cleanup,
which
could result in a network definition with interfaces in the pool that
were NULL. This would in turn lead to a libvirtd crash when a guest
tried to attach an interface using the network with that pool.
In particular this would happen when creating a pool to be used for
macvtap connections. macvtap needs the netdev name of the virtual
function in order to use it, and each VF only has a netdev name if it
is currently bound to a network driver. If one of the VFs of a PF
happened to be bound to the pci-stub or vfio-pci driver (indicating
it's already in use for PCI passthrough), or no driver at all, it
would have no name. In this case networkCreateInterfacePool would
return an error, but would leave the netdef->forward.nifs set to the
total number of VFs in the PF. The interface attach that triggered
calling of networkCreateInterfacePool (it uses a "lazy fill" strategy)
would simply fail, but the very next attempt to attach an interface
using the same network pool would result in a crash.
This patch refactors networkCreateInterfacePool to bring it more in
line with current coding practices (label name, use of a switch with
no default case) as well as providing the following two changes to
behavior:
1) If a VF with no netdev name is encountered, just log a warning and
continue; only fail if exactly 0 devices are found to put in the pool.
2) If the function fails, clean up any partial interface pool and set
netdef->forward.nifs to 0.
This resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=1111455
---
src/network/bridge_driver.c | 113 ++++++++++++++++++++++++++++----------------
1 file changed, 73 insertions(+), 40 deletions(-)
+ cleanup:
+ if (ret < 0) {
+ /* free all the entries made before error */
+ for (i= 0; i < netdef->forward.nifs; i++) {
Space before =
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library