1. 04 12月, 2018 1 次提交
  2. 28 11月, 2018 2 次提交
  3. 27 11月, 2018 13 次提交
  4. 26 11月, 2018 8 次提交
  5. 23 11月, 2018 8 次提交
    • G
      9p: fix QEMU crash when renaming files · 1d203986
      Greg Kurz 提交于
      When using the 9P2000.u version of the protocol, the following shell
      command line in the guest can cause QEMU to crash:
      
          while true; do rm -rf aa; mkdir -p a/b & touch a/b/c & mv a aa; done
      
      With 9P2000.u, file renaming is handled by the WSTAT command. The
      v9fs_wstat() function calls v9fs_complete_rename(), which calls
      v9fs_fix_path() for every fid whose path is affected by the change.
      The involved calls to v9fs_path_copy() may race with any other access
      to the fid path performed by some worker thread, causing a crash like
      shown below:
      
      Thread 12 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
      0x0000555555a25da2 in local_open_nofollow (fs_ctx=0x555557d958b8, path=0x0,
       flags=65536, mode=0) at hw/9pfs/9p-local.c:59
      59          while (*path && fd != -1) {
      (gdb) bt
      #0  0x0000555555a25da2 in local_open_nofollow (fs_ctx=0x555557d958b8,
       path=0x0, flags=65536, mode=0) at hw/9pfs/9p-local.c:59
      #1  0x0000555555a25e0c in local_opendir_nofollow (fs_ctx=0x555557d958b8,
       path=0x0) at hw/9pfs/9p-local.c:92
      #2  0x0000555555a261b8 in local_lstat (fs_ctx=0x555557d958b8,
       fs_path=0x555556b56858, stbuf=0x7fff84830ef0) at hw/9pfs/9p-local.c:185
      #3  0x0000555555a2b367 in v9fs_co_lstat (pdu=0x555557d97498,
       path=0x555556b56858, stbuf=0x7fff84830ef0) at hw/9pfs/cofile.c:53
      #4  0x0000555555a1e9e2 in v9fs_stat (opaque=0x555557d97498)
       at hw/9pfs/9p.c:1083
      #5  0x0000555555e060a2 in coroutine_trampoline (i0=-669165424, i1=32767)
       at util/coroutine-ucontext.c:116
      #6  0x00007fffef4f5600 in __start_context () at /lib64/libc.so.6
      #7  0x0000000000000000 in  ()
      (gdb)
      
      The fix is to take the path write lock when calling v9fs_complete_rename(),
      like in v9fs_rename().
      
      Impact:  DoS triggered by unprivileged guest users.
      
      Fixes: CVE-2018-19489
      Cc: P J P <ppandit@redhat.com>
      Reported-by: Nzhibin hu <noirfate@gmail.com>
      Reviewed-by: NPrasad J Pandit <pjp@fedoraproject.org>
      Signed-off-by: NGreg Kurz <groug@kaod.org>
      1d203986
    • P
      Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging · 5298f4d6
      Peter Maydell 提交于
      Block layer patches:
      
      - block: Fix update of BDRV_O_AUTO_RDONLY in update_flags_from_options()
      - block: Fix option inheritance after stream/commit job graph changes
      - qemu-img: Fix memory leak and typo in error message
      - nvme: Fixes for lockups and crashes
      - scsi-disk: Fix crash if underlying host file or disk returns error
      - Several qemu-iotests fixes and improvements
      
      # gpg: Signature made Thu 22 Nov 2018 18:38:30 GMT
      # gpg:                using RSA key 7F09B272C88F2FD6
      # gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>"
      # Primary key fingerprint: DC3D EB15 9A9A F95D 3D74  56FE 7F09 B272 C88F 2FD6
      
      * remotes/kevin/tags/for-upstream:
        block: Update BlockDriverState.inherits_from on bdrv_drop_intermediate()
        block: Update BlockDriverState.inherits_from on bdrv_set_backing_hd()
        iotests: Enhance 223 to cover multiple bitmap granularities
        nvme: fix bug with PCI IRQ pins on teardown
        nvme: fix CMB endianness confusion
        Revert "nvme: fix oob access issue(CVE-2018-16847)"
        nvme: fix out-of-bounds access to the CMB
        nvme: call blk_drain in NVMe reset code to avoid lockups
        iotests: fix nbd test 233 to work correctly with raw images
        block: Fix update of BDRV_O_AUTO_RDONLY in update_flags_from_options()
        scsi-disk: Fix crash if underlying host file or disk returns error
        qemu-img: Fix leak
        qemu-img: Fix typo
        iotests: Skip 233 if certtool not installed
        iotests: Replace assertEquals() with assertEqual()
        iotests: Replace time.clock() with Timeout
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      5298f4d6
    • M
      895e4897
    • A
      block: Update BlockDriverState.inherits_from on bdrv_drop_intermediate() · 6bd858b3
      Alberto Garcia 提交于
      The previous patch fixed the inherits_from pointer after block-stream,
      and this one does the same for block-commit.
      
      When block-commit finishes and the 'top' node is not the topmost one
      from the backing chain then all nodes above 'base' up to and including
      'top' are removed from the chain.
      
      The bdrv_drop_intermediate() call converts a chain like this one:
      
          base <- intermediate <- top <- active
      
      into this one:
      
          base <- active
      
      In a simple scenario each backing file from the first chain has the
      inherits_from attribute pointing to its parent. This means that
      reopening 'active' will recursively reopen all its children, whose
      options can be changed in the process.
      
      However after the 'block-commit' call base.inherits_from is NULL and
      the chain is broken, so 'base' does not inherit from 'active' and will
      not be reopened automatically:
      
         $ qemu-img create -f qcow2 hd0.qcow2 1M
         $ qemu-img create -f qcow2 -b hd0.qcow2 hd1.qcow2
         $ qemu-img create -f qcow2 -b hd1.qcow2 hd2.qcow2
         $ $QEMU -drive if=none,file=hd2.qcow2
      
         { 'execute': 'block-commit',
           'arguments': {
             'device': 'none0',
             'top': 'hd1.qcow2' } }
      
         { 'execute': 'human-monitor-command',
           'arguments': {
              'command-line':
                'qemu-io none0 "reopen -o backing.l2-cache-size=2M"' } }
      
         { "return": "Cannot change the option 'backing.l2-cache-size'\r\n"}
      
      This patch updates base.inherits_from in this scenario, and adds a
      test case.
      Signed-off-by: NAlberto Garcia <berto@igalia.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      6bd858b3
    • A
      block: Update BlockDriverState.inherits_from on bdrv_set_backing_hd() · 0065c455
      Alberto Garcia 提交于
      When a BlockDriverState's child is opened (be it a backing file, the
      protocol layer, or any other) inherits_from is set to point to the
      parent node. Children opened separately and then attached to a parent
      don't have this pointer set.
      
      bdrv_reopen_queue_child() uses this to determine whether a node's
      children must also be reopened inheriting the options from the parent
      or not. If inherits_from points to the parent then the child is
      reopened and its options can be changed, like in this example:
      
         $ qemu-img create -f qcow2 hd0.qcow2 1M
         $ qemu-img create -f qcow2 hd1.qcow2 1M
         $ $QEMU -drive if=none,node-name=hd0,file=hd0.qcow2,\
                        backing.driver=qcow2,backing.file.filename=hd1.qcow2
         (qemu) qemu-io hd0 "reopen -o backing.l2-cache-size=2M"
      
      If the child does not inherit from the parent then it does not get
      reopened and its options cannot be changed:
      
         $ $QEMU -drive if=none,node-name=hd1,file=hd1.qcow2
                 -drive if=none,node-name=hd0,file=hd0.qcow2,backing=hd1
         (qemu) qemu-io hd0 "reopen -o backing.l2-cache-size=2M"
         Cannot change the option 'backing.l2-cache-size'
      
      If a disk image has a chain of backing files then all of them are also
      connected through their inherits_from pointers (i.e. it's possible to
      walk the chain in reverse order from base to top).
      
      However this is broken if the intermediate nodes are removed using
      e.g. block-stream because the inherits_from pointer from the base node
      becomes NULL:
      
         $ qemu-img create -f qcow2 hd0.qcow2 1M
         $ qemu-img create -f qcow2 -b hd0.qcow2 hd1.qcow2
         $ qemu-img create -f qcow2 -b hd1.qcow2 hd2.qcow2
         $ $QEMU -drive if=none,file=hd2.qcow2
         (qemu) qemu-io none0 "reopen -o backing.l2-cache-size=2M"
         (qemu) block_stream none0 0 hd0.qcow2
         (qemu) qemu-io none0 "reopen -o backing.l2-cache-size=2M"
         Cannot change the option 'backing.l2-cache-size'
      
      This patch updates the inherits_from pointer if the intermediate nodes
      of a backing chain are removed using bdrv_set_backing_hd(), and adds a
      test case for this scenario.
      Signed-off-by: NAlberto Garcia <berto@igalia.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      0065c455
    • E
      iotests: Enhance 223 to cover multiple bitmap granularities · a237dea3
      Eric Blake 提交于
      Testing granularity at the same size as the cluster isn't quite
      as fun as what happens when it is larger or smaller.  This
      enhancement also shows that qemu's nbd server can serve the
      same disk over multiple exports simultaneously.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Tested-by: NJohn Snow <jsnow@redhat.com>
      Reviewed-by: NJohn Snow <jsnow@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      a237dea3
    • L
      nvme: fix bug with PCI IRQ pins on teardown · ad3a7e45
      Logan Gunthorpe 提交于
      When the submission and completion queues are being torn down
      the IRQ will be asserted for the completion queue when the
      submsission queue is deleted. Then when the completion queue
      is deleted it stays asserted. Thus, on systems that do
      not use MSI, no further interrupts can be triggered on the host.
      
      Linux sees this as a long delay when unbinding the nvme device.
      Eventually the interrupt timeout occurs and it continues.
      
      To fix this we ensure we deassert the IRQ for a CQ when it is
      deleted.
      Signed-off-by: NLogan Gunthorpe <logang@deltatee.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      ad3a7e45
    • P
      nvme: fix CMB endianness confusion · 71a86dde
      Paolo Bonzini 提交于
      The CMB is marked as DEVICE_LITTLE_ENDIAN, so the data must be
      read/written as if it was little-endian output (in the case of
      big endian, we get two swaps, one in the memory core and one
      in nvme.c).
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Tested-by: NPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      71a86dde
  6. 22 11月, 2018 8 次提交