1. 30 6月, 2016 1 次提交
  2. 23 1月, 2015 5 次提交
  3. 14 11月, 2014 1 次提交
    • L
      util: eliminate "use after free" in callers of virNetDevLinkDump · 56f11b41
      Laine Stump 提交于
      virNetDevLinkDump() gets a message from netlink into "resp", then
      calls nlmsg_parse() to fill the table "tb" with pointers into resp. It
      then returns tb to its caller, but not before freeing the buffer at
      resp. That means that all the callers of virNetDevLinkDump() are
      examining memory that has already been freed. This can be verified by
      filling the buffer at resp with garbage prior to freeing it (or, I
      suppose, just running libvirtd under valgrind) then performing some
      operation that calls virNetDevLinkDump().
      
      The upstream commit log incorrectly states that the code has been like
      this ever since virNetDevLinkDump() was written. In reality, the
      problem was introduced with commit e95de74d, first in libvirt-1.0.5,
      which was attempting to eliminate a typecast that caused compiler
      warnings. It has only been pure luck (or maybe a lack of heavy load,
      and/or maybe an allocation algorithm in malloc() that delays re-use of
      just-freed memory) that has kept this from causing errors, for example
      when configuring a PCI passthrough or macvtap passthrough network
      interface.
      
      The solution taken in this patch is the simplest - just return resp to
      the caller along with tb, then have the caller free it after they are
      finished using the data (pointers) in tb. I alternately could have
      made a cleaner interface by creating a new struct that put tb and resp
      together along with a vir*Free() function for it, but this function is
      only used in a couple places, and I'm not sure there will be
      additional new uses of virNetDevLinkDump(), so the value of adding a
      new type, extra APIs, etc. is dubious.
      
      (cherry picked from commit f9f9699f)
      
      Conflicts:
      	src/util/virnetdevvportprofile.c - whitespace/copyright change
      56f11b41
  4. 11 11月, 2014 1 次提交
    • E
      CVE-2014-7823: dumpxml: security hole with migratable flag · 333c95c9
      Eric Blake 提交于
      Commit 28f8dfdc (v1.0.0) introduced a security hole: in at least
      the qemu implementation of virDomainGetXMLDesc, the use of the
      flag VIR_DOMAIN_XML_MIGRATABLE (which is usable from a read-only
      connection) triggers the implicit use of VIR_DOMAIN_XML_SECURE
      prior to calling qemuDomainFormatXML.  However, the use of
      VIR_DOMAIN_XML_SECURE is supposed to be restricted to read-write
      clients only.  This patch treats the migratable flag as requiring
      the same permissions, rather than analyzing what might break if
      migratable xml no longer includes secret information.
      
      Fortunately, the information leak is low-risk: all that is gated
      by the VIR_DOMAIN_XML_SECURE flag is the VNC connection password;
      but VNC passwords are already weak (FIPS forbids their use, and
      on a non-FIPS machine, anyone stupid enough to trust a max-8-byte
      password sent in plaintext over the network deserves what they
      get).  SPICE offers better security than VNC, and all other
      secrets are properly protected by use of virSecret associations
      rather than direct output in domain XML.
      
      * src/remote/remote_protocol.x (REMOTE_PROC_DOMAIN_GET_XML_DESC):
      Tighten rules on use of migratable flag.
      * src/libvirt-domain.c (virDomainGetXMLDesc): Likewise.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      (cherry picked from commit b1674ad5)
      
      Conflicts:
      	src/libvirt-domain.c - file split from older src/libvirt.c; context with older virLibConnError
      	src/remote/remote_protocol.x - no fine-grained ACLs
      Signed-off-by: NEric Blake <eblake@redhat.com>
      333c95c9
  5. 02 10月, 2014 1 次提交
  6. 22 9月, 2014 1 次提交
    • G
      python: return dictionary without value in case of no blockjob · 1e6be023
      Guannan Ren 提交于
      Currently, when there is no blockjob, dom.blockJobInfo('vda')
      still reports error because it doesn't distinguish return value 0 from -1.
      libvirt.libvirtError: virDomainGetBlockJobInfo() failed
      
      virDomainGetBlockJobInfo() API return value:
       -1 in case of failure, 0 when nothing found, 1 found.
      
      And use PyDict_SetItemString instead of PyDict_SetItem when key is
      of string type. PyDict_SetItemString increments key/value reference
      count, so call Py_DECREF() for value. For key, we don't need to
      do this, because PyDict_SetItemString will handle it internally.
      
      (cherry picked from commit 0f9e67bf)
      1e6be023
  7. 18 9月, 2014 2 次提交
  8. 03 7月, 2014 2 次提交
    • P
      qemu: copy: Accept 'format' parameter when copying to a non-existing img · 4fb55871
      Peter Krempa 提交于
      We have the following matrix of possible arguments handled by the logic
      statement touched by this patch:
             | flags & _REUSE_EXT | !(flags & _REUSE_EXT)
      -------+--------------------+----------------------
       format| (1)                | (2)
      -------+--------------------+----------------------
      !format| (3)                | (4)
      -------+--------------------+----------------------
      
      In cases 1 and 2 the user provided a format, in cases 3 and 4 not. The
      user requests to use a pre-existing image in 1 and 3 and libvirt will
      create a new image in 2 and 4.
      
      The difference between cases 3 and 4 is that for 3 the format is probed
      from the user-provided image, whereas in 4 we just use the existing disk
      format.
      
      The current code would treat cases 1,3 and 4 correctly but in case 2 the
      format provided by the user would be ignored.
      
      The particular piece of code was broken in commit 35c7701c
      but since it was introduced a few commits before that it was never
      released as working.
      
      (cherry picked from commit 42619ed0)
      Signed-off-by: NEric Blake <eblake@redhat.com>
      
      Conflicts:
      	src/qemu/qemu_driver.c - no refactoring of commits 7b7bf001, 4f202266
      4fb55871
    • E
      build: fix 'make check' with newer git · 1e12069e
      Eric Blake 提交于
      Newer git doesn't like the maint.mk rule 'public-submodule-commit'
      run during 'make check', as inherited from our checkout of gnulib.
      I tracked down that libvirt commit 8531301d picked up a gnulib fix
      that makes git happy.  Rather than try and do a full .gnulib
      submodule update to gnulib.git d18d1b802 (as used in that libvirt
      commit), it was easier to just backport the fixed maint.mk from
      gnulib on top of our existing submodule level.  I did it as follows,
      where these steps will have to be repeated when cherry-picking this
      commit to any other maintenance branch:
      
      mkdir -p gnulib/local/top
      cd .gnulib
      git checkout d18d1b802 top/maint.mk
      git diff HEAD > ../gnulib/local/top/maint.mk.diff
      git reset --hard
      cd ..
      git add gnulib/local/top
      Signed-off-by: NEric Blake <eblake@redhat.com>
      1e12069e
  9. 27 6月, 2014 2 次提交
    • E
      docs: publish correct enum values · b096e694
      Eric Blake 提交于
      We publish libvirt-api.xml for others to use, and in fact, the
      libvirt-python bindings use it to generate python constants that
      correspond to our enum values.  However, we had an off-by-one bug
      that any enum that relied on C's rules for implicit initialization
      of the first enum member to 0 got listed in the xml as having a
      value of 1 (and all later members of the enum were equally
      botched).
      
      The fix is simple - since we add one to the previous value when
      encountering an enum without an initializer, the previous value
      must start at -1 so that the first enum member is assigned 0.
      
      The python generator code has had the off-by-one ever since DV
      first wrote it years ago, but most of our public enums were immune
      because they had an explicit = 0 initializer.  The only affected
      enums are:
      - virDomainEventGraphicsAddressType (such as
      VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV4), since commit 987e31ed
      (libvirt v0.8.0)
      - virDomainCoreDumpFormat (such as VIR_DOMAIN_CORE_DUMP_FORMAT_RAW),
      since commit 9fbaff00 (libvirt v1.2.3)
      - virIPAddrType (such as VIR_IP_ADDR_TYPE_IPV4), since commit
      03e0e79e (not yet released)
      
      Thanks to Nehal J Wani for reporting the problem on IRC, and
      for helping me zero in on the culprit function.
      
      * docs/apibuild.py (CParser.parseEnumBlock): Fix implicit enum
      values.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      (cherry picked from commit 9b291bbe)
      
      Conflicts:
      	docs/apibuild.py - context with 2a409511
      b096e694
    • P
      qemu: blockcopy: Don't remove existing disk mirror info · 0e307ecf
      Peter Krempa 提交于
      When creating a new disk mirror the new struct is stored in a separate
      variable until everything went well. The removed hunk would actually
      remove existing mirror information for example when the api would be run
      if a mirror still exists.
      
      (cherry picked from commit 02b364e1)
      
      This fixes a regression introduced in commit ff5f30b6.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      
      Conflicts:
      	src/qemu/qemu_driver.c - no refactoring of commits 7b7bf001, 4f202266
      0e307ecf
  10. 01 5月, 2014 1 次提交
  11. 10 4月, 2014 4 次提交
  12. 20 3月, 2014 1 次提交
    • M
      virNetClientSetTLSSession: Restore original signal mask · 5abdbf13
      Michal Privoznik 提交于
      Currently, we use pthread_sigmask(SIG_BLOCK, ...) prior to calling
      poll(). This is okay, as we don't want poll() to be interrupted.
      However, then - immediately as we fall out from the poll() - we try to
      restore the original sigmask - again using SIG_BLOCK. But as the man
      page says, SIG_BLOCK adds signals to the signal mask:
      
      SIG_BLOCK
            The set of blocked signals is the union of the current set and the set argument.
      
      Therefore, when restoring the original mask, we need to completely
      overwrite the one we set earlier and hence we should be using:
      
      SIG_SETMASK
            The set of blocked signals is set to the argument set.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      (cherry picked from commit 3d4b4f5a)
      5abdbf13
  13. 10 3月, 2014 1 次提交
    • D
      Add a mutex to serialize updates to firewall · b4aa48c7
      Daniel P. Berrange 提交于
      The nwfilter conf update mutex previously serialized
      updates to the internal data structures for firewall
      rules, and updates to the firewall itself. The latter
      was recently turned into a read/write lock, and filter
      instantiation allowed to proceed in parallel. It was
      believed that this was ok, since each filter is created
      on a separate iptables/ebtables chain.
      
      It turns out that there is a subtle lock ordering problem
      on virNWFilterObjPtr instances. __virNWFilterInstantiateFilter
      will hold a lock on the virNWFilterObjPtr it is instantiating.
      This in turn invokes virNWFilterInstantiate which then invokes
      virNWFilterDetermineMissingVarsRec which then invokes
      virNWFilterObjFindByName. This iterates over every single
      virNWFilterObjPtr in the list, locking them and checking their
      name. So if 2 or more threads try to instantiate a filter in
      parallel, they'll all hold 1 lock at the top level in the
      __virNWFilterInstantiateFilter method which will cause the
      other thread to deadlock in virNWFilterObjFindByName.
      
      The fix is to add an exclusive mutex to serialize the
      execution of __virNWFilterInstantiateFilter.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      (cherry picked from commit 925de19e)
      
      Conflicts:
      	src/nwfilter/nwfilter_gentech_driver.c
      b4aa48c7
  14. 19 2月, 2014 17 次提交