1. 30 6月, 2016 1 次提交
  2. 11 11月, 2014 1 次提交
    • E
      CVE-2014-7823: dumpxml: security hole with migratable flag · 7b334c16
      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>
      7b334c16
  3. 02 10月, 2014 1 次提交
  4. 18 9月, 2014 2 次提交
  5. 03 7月, 2014 2 次提交
    • P
      qemu: copy: Accept 'format' parameter when copying to a non-existing img · 20326db6
      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, b090aa7d
      20326db6
    • E
      build: fix 'make check' with newer git · fdcd63fe
      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>
      fdcd63fe
  6. 27 6月, 2014 2 次提交
    • E
      docs: publish correct enum values · de8545c8
      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
      de8545c8
    • P
      qemu: blockcopy: Don't remove existing disk mirror info · 2d03487b
      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, a88fb300, 632f78ca, b090aa7d
      2d03487b
  7. 01 5月, 2014 1 次提交
  8. 20 3月, 2014 1 次提交
    • M
      virNetClientSetTLSSession: Restore original signal mask · f4d67fdb
      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)
      f4d67fdb
  9. 16 1月, 2014 9 次提交
    • J
      Really don't crash if a connection closes early · 7fad864a
      Jiri Denemark 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1047577
      
      When writing commit 173c2914, I missed the fact virNetServerClientClose
      unlocks the client object before actually clearing client->sock and thus
      it is possible to hit a window when client->keepalive is NULL while
      client->sock is not NULL. I was thinking client->sock == NULL was a
      better check for a closed connection but apparently we have to go with
      client->keepalive == NULL to actually fix the crash.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      (cherry picked from commit 066c8ef6)
      7fad864a
    • J
      Don't crash if a connection closes early · e3ca9d3d
      Jiri Denemark 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1047577
      
      When a client closes its connection to libvirtd early during
      virConnectOpen, more specifically just after making
      REMOTE_PROC_CONNECT_SUPPORTS_FEATURE call to check if
      VIR_DRV_FEATURE_PROGRAM_KEEPALIVE is supported without even waiting for
      the result, libvirtd may crash due to a race in keep-alive
      initialization. Once receiving the REMOTE_PROC_CONNECT_SUPPORTS_FEATURE
      call, the daemon's event loop delegates it to a worker thread. In case
      the event loop detects EOF on the connection and calls
      virNetServerClientClose before the worker thread starts to handle
      REMOTE_PROC_CONNECT_SUPPORTS_FEATURE call, client->keepalive will be
      disposed by the time virNetServerClientStartKeepAlive gets called from
      remoteDispatchConnectSupportsFeature. Because the flow is common for
      both authenticated and read-only connections, even unprivileged clients
      may cause the daemon to crash.
      
      To avoid the crash, virNetServerClientStartKeepAlive needs to check if
      the connection is still open before starting keep-alive protocol.
      
      Every libvirt release since 0.9.8 is affected by this bug.
      
      (cherry picked from commit 173c2914)
      e3ca9d3d
    • J
      qemu: Fix job usage in virDomainGetBlockIoTune · d0a4e249
      Jiri Denemark 提交于
      CVE-2013-6458
      
      Every API that is going to begin a job should do that before fetching
      data from vm->def.
      
      (cherry picked from commit 3b564259)
      
      Conflicts:
      	src/qemu/qemu_driver.c - older BeginJobWithDriver
      d0a4e249
    • J
      qemu: Fix job usage in qemuDomainBlockCopy · c5683680
      Jiri Denemark 提交于
      Every API that is going to begin a job should do that before fetching
      data from vm->def.
      
      (cherry picked from commit ff5f30b6)
      
      Conflicts:
      	src/qemu/qemu_driver.c - context
      c5683680
    • J
      qemu: Fix job usage in qemuDomainBlockJobImpl · c973eb03
      Jiri Denemark 提交于
      CVE-2013-6458
      
      Every API that is going to begin a job should do that before fetching
      data from vm->def.
      
      (cherry picked from commit f93d2caa)
      
      Conflicts:
      	src/qemu/qemu_driver.c - older style BeginJobWithDriver
      c973eb03
    • J
      qemu: Avoid using stale data in virDomainGetBlockInfo · 324279f2
      Jiri Denemark 提交于
      CVE-2013-6458
      
      Generally, every API that is going to begin a job should do that before
      fetching data from vm->def. However, qemuDomainGetBlockInfo does not
      know whether it will have to start a job or not before checking vm->def.
      To avoid using disk alias that might have been freed while we were
      waiting for a job, we use its copy. In case the disk was removed in the
      meantime, we will fail with "cannot find statistics for device '...'"
      error message.
      
      (cherry picked from commit b7992595)
      
      Conflicts:
      	src/qemu/qemu_driver.c - VIR_STRDUP not backported, context
      324279f2
    • J
      qemu: Do not access stale data in virDomainBlockStats · 561b03f9
      Jiri Denemark 提交于
      CVE-2013-6458
      https://bugzilla.redhat.com/show_bug.cgi?id=1043069
      
      When virDomainDetachDeviceFlags is called concurrently to
      virDomainBlockStats: libvirtd may crash because qemuDomainBlockStats
      finds a disk in vm->def before getting a job on a domain and uses the
      disk pointer after getting the job. However, the domain in unlocked
      while waiting on a job condition and thus data behind the disk pointer
      may disappear. This happens when thread 1 runs
      virDomainDetachDeviceFlags and enters monitor to actually remove the
      disk. Then another thread starts running virDomainBlockStats, finds the
      disk in vm->def, and while it's waiting on the job condition (owned by
      the first thread), the first thread finishes the disk removal. When the
      second thread gets the job, the memory pointed to be the disk pointer is
      already gone.
      
      That said, every API that is going to begin a job should do that before
      fetching data from vm->def.
      
      (cherry picked from commit db86da5c)
      
      Conflicts:
      	src/qemu/qemu_driver.c - context: no ACLs
      561b03f9
    • E
      build: use proper pod for nested bulleted VIRSH_DEBUG list · 939edc41
      Eric Blake 提交于
      Newer pod (hello rawhide) complains if you attempt to mix bullets
      and non-bullets in the same list:
      
      virsh.pod around line 3177: Expected text after =item, not a bullet
      
      As our intent was to nest an inner list, we make that explicit to
      keep pod happy.
      
      * tools/virsh.pod (ENVIRONMENT): Use correct pod syntax.
      
      (cherry picked from commit 00d69b4a)
      939edc41
    • J
      libxl: fix build with Xen4.3 · c4c6fc42
      Jim Fehlig 提交于
      Xen 4.3 fixes a mistake in the libxl event handler signature where the
      event owned by the application was defined as const.  Detect this and
      define the libvirt libxl event handler signature appropriately.
      (cherry picked from commit 43b0ff5b)
      c4c6fc42
  10. 18 10月, 2013 1 次提交
  11. 19 9月, 2013 5 次提交
    • D
      Fix crash in remoteDispatchDomainMemoryStats (CVE-2013-4296) · 9579f457
      Daniel P. Berrange 提交于
      The 'stats' variable was not initialized to NULL, so if some
      early validation of the RPC call fails, it is possible to jump
      to the 'cleanup' label and VIR_FREE an uninitialized pointer.
      This is a security flaw, since the API can be called from a
      readonly connection which can trigger the validation checks.
      
      This was introduced in release v0.9.1 onwards by
      
        commit 158ba873
        Author: Daniel P. Berrange <berrange@redhat.com>
        Date:   Wed Apr 13 16:21:35 2011 +0100
      
          Merge all returns paths from dispatcher into single path
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      (cherry picked from commit e7f400a1)
      
      Conflicts:
      	daemon/remote.c - context
      9579f457
    • D
      Fix deps for generating RPC dispatch code · bbdbe190
      Daniel P. Berrange 提交于
      The src/lxc/lxc_*_dispatch.h files only had deps on the
      RPC generator script & the XDR definition file. So when
      the Makefile.am args passed to the generator were change,
      the disaptch code was not re-generated. This caused a
      build failure
      
        CC       libvirt_lxc-lxc_controller.o
      lxc/lxc_controller.c: In function 'virLXCControllerSetupServer':
      lxc/lxc_controller.c:718:47: error: 'virLXCMonitorProcs' undeclared (first use in this function)
      lxc/lxc_controller.c:718:47: note: each undeclared identifier is reported only once for each function it appears in
      lxc/lxc_controller.c:719:47: error: 'virLXCMonitorNProcs' undeclared (first use in this function)
      make[3]: *** [libvirt_lxc-lxc_controller.o] Error 1
      
      For added fun, the generated files were not listed in
      CLEANFILES, so only a 'git clean -f' would fix the build
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      (cherry picked from commit 0946c5f5)
      bbdbe190
    • D
      Add support for using 3-arg pkcheck syntax for process (CVE-2013-4311) · 30cf3b74
      Daniel P. Berrange 提交于
      With the existing pkcheck (pid, start time) tuple for identifying
      the process, there is a race condition, where a process can make
      a libvirt RPC call and in another thread exec a setuid application,
      causing it to change to effective UID 0. This in turn causes polkit
      to do its permission check based on the wrong UID.
      
      To address this, libvirt must get the UID the caller had at time
      of connect() (from SO_PEERCRED) and pass a (pid, start time, uid)
      triple to the pkcheck program.
      Signed-off-by: NColin Walters <walters@redhat.com>
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      (cherry picked from commit 922b7fda)
      
      Conflicts:
      	src/access/viraccessdriverpolkit.c
      
      Resolution:
        Dropped file that does not exist in this branch.
      30cf3b74
    • D
      Include process start time when doing polkit checks · eec80bcd
      Daniel P. Berrange 提交于
      Since PIDs can be reused, polkit prefers to be given
      a (PID,start time) pair. If given a PID on its own,
      it will attempt to lookup the start time in /proc/pid/stat,
      though this is subject to races.
      
      It is safer if the client app resolves the PID start
      time itself, because as long as the app has the client
      socket open, the client PID won't be reused.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      (cherry picked from commit 979e9c56)
      
      Conflicts:
      	src/util/virprocess.c
      	src/util/virstring.c
      	src/util/virstring.h
      	src/rpc/virnetserverclient.c
      	src/rpc/virnetsocket.h
      	src/util/viridentity.h
      eec80bcd
    • D
      Fix TLS tests with gnutls 3 · e4c674f8
      Daniel P. Berrange 提交于
      When given a CA cert with basic constraints to set non-critical,
      and key usage of 'key signing', this should be rejected. Version
      of GNUTLS < 3 do not rejecte it though, so we never noticed the
      test case was broken
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      (cherry picked from commit 0204d6d7)
      e4c674f8
  12. 01 7月, 2013 1 次提交
  13. 27 6月, 2013 2 次提交
  14. 16 5月, 2013 1 次提交
    • J
      daemon: fix leak after listing all volumes · 89c74908
      Ján Tomko 提交于
      CVE-2013-1962
      
      remoteDispatchStoragePoolListAllVolumes wasn't freeing the pool.
      The pool also held a reference to the connection, preventing it from
      getting freed and closing the netcf interface driver, which held two
      sockets open.
      (cherry picked from commit ca697e90)
      89c74908
  15. 20 3月, 2013 1 次提交
    • D
      Fix --without-libvirtd builds · b97a2fc1
      Doug Goldstein 提交于
      When building with --without-libvirtd and udev support is detected we
      will fail to build with the following error:
          node_device/node_device_udev.c:1608:37: error: unknown type name
              'virStateInhibitCallback'
      (cherry picked from commit 52ad612c)
      b97a2fc1
  16. 20 2月, 2013 2 次提交
  17. 09 2月, 2013 3 次提交
  18. 30 1月, 2013 4 次提交
    • D
      Release of libvirt-1.0.2 · 4a824cdb
      Daniel Veillard 提交于
      * configure.ac docs/news.html.in libvirt.spec.in: update for the release
      * po/*.po*: updated localizations
      4a824cdb
    • M
      Ignore '.trs' files · 3d36b1a4
      Martin Kletzander 提交于
      When doing checks with automake, there are '<testname>.trs' files left
      behind, that might or might not be usable, however these show up in
      'git status' even though we definitely don't want them to be tracked
      in the repository'.  Automake adds the '--trs-files' option by default
      since commit 0c81b43f711fb861f04227ced8dba889596d9c43 [1], which
      consequently (from 1.13 in my case) started leaving these files behind
      along with '<testname>.log' files as well (which we already ignore).
      
      [1] http://git.savannah.gnu.org/gitweb/?p=automake.git;a=commitdiff;h=0c81b43
      3d36b1a4
    • M
      docs: aesthetical cleanups · 901f4b6b
      Martin Kletzander 提交于
      Adding dots inside "exempli gratia" where missing.  While on that, I
      took the liberty of changing it where found with simple grep.
      901f4b6b
    • M
      conf: Don't format cputune element when not needed · 1f50730e
      Martin Kletzander 提交于
      Commit 60b176c3 introduced a bug that
      when editing an XML with cputune similar to this:
      
      ...
        <vcpu placement='static' current='1'>2</vcpu>
        <cputune>
          <vcpupin vcpu="1" cpuset="0"/>
        </cputune>
      ...
      
      results in formatted XML that looks like this:
      
      ...
        <vcpu placement='static' current='1'>2</vcpu>
        <cputune>
        </cputune>
      ...
      
      That is caused by a condition depending on def->cputune.vcpupin being
      set rather than checking def->cputune.nvcpupin.  Notice that nvcpupin
      can be 0 and vcpupin can still be allocated since it's a pointer to an
      array, so no harm done there.
      
      I also changed it on other places in the code where it depended on the
      wrong variable.
      1f50730e
新手
引导
客服 返回
顶部