Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 12 12月, 2018 5 次提交
  3. 06 12月, 2018 1 次提交
  5. 04 12月, 2018 2 次提交
  7. 03 12月, 2018 1 次提交
  9. 28 11月, 2018 1 次提交
  11. 27 11月, 2018 9 次提交
  13. 26 11月, 2018 2 次提交
  15. 23 11月, 2018 3 次提交
    • 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
    • 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
  17. 22 11月, 2018 5 次提交
  19. 20 11月, 2018 2 次提交
  21. 19 11月, 2018 5 次提交
  23. 15 11月, 2018 1 次提交
  25. 14 11月, 2018 1 次提交
  27. 13 11月, 2018 2 次提交