qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 3b9717: net: check fragment length during fra


From: GitHub
Subject: [Qemu-commits] [qemu/qemu] 3b9717: net: check fragment length during fragmentation
Date: Thu, 29 Sep 2016 14:30:06 -0700

  Branch: refs/heads/stable-2.6
  Home:   https://github.com/qemu/qemu
  Commit: 3b9717a62bf5882abaf6602c077cdbe63dffc35e
      
https://github.com/qemu/qemu/commit/3b9717a62bf5882abaf6602c077cdbe63dffc35e
  Author: Prasad J Pandit <address@hidden>
  Date:   2016-09-08 (Thu, 08 Sep 2016)

  Changed paths:
    M hw/net/vmxnet_tx_pkt.c

  Log Message:
  -----------
  net: check fragment length during fragmentation

Network transport abstraction layer supports packet fragmentation.
While fragmenting a packet, it checks for more fragments from
packet length and current fragment length. It is susceptible
to an infinite loop, if the current fragment length is zero.
Add check to avoid it.

Reported-by: Li Qiang <address@hidden>
Signed-off-by: Prasad J Pandit <address@hidden>
Reviewed-by: Dmitry Fleytman <address@hidden>
CC: address@hidden
Signed-off-by: Jason Wang <address@hidden>
(cherry picked from commit ead315e43ea0c2ca3491209c6c8db8ce3f2bbe05)
Signed-off-by: Michael Roth <address@hidden>


  Commit: d00d89a685ae8d1ac8c600127962c29773b96d79
      
https://github.com/qemu/qemu/commit/d00d89a685ae8d1ac8c600127962c29773b96d79
  Author: Daniel P. Berrange <address@hidden>
  Date:   2016-09-08 (Thu, 08 Sep 2016)

  Changed paths:
    M ui/vnc.c

  Log Message:
  -----------
  ui: fix refresh of VNC server surface

In previous commit

  commit c7628bff4138ce906a3620d12e0820c1cf6c140d
  Author: Gerd Hoffmann <address@hidden>
  Date:   Fri Oct 30 12:10:09 2015 +0100

    vnc: only alloc server surface with clients connected

the VNC server was changed so that the 'vd->server' pixman
image was only allocated when a client is connected.

Since then if a client disconnects and then reconnects to
the VNC server all they will see is a black screen until
they do something that triggers a refresh. On a graphical
desktop this is not often noticed since there's many things
going on which cause a refresh. On a plain text console it
is really obvious since nothing refreshes frequently.

The problem is that the VNC server didn't update the guest
dirty bitmap, so still believes its server image is in sync
with the guest contents.

To fix this we must explicitly mark the entire guest desktop
as dirty after re-creating the server surface. Move this
logic into vnc_update_server_surface() so it is guaranteed
to be call in all code paths that re-create the surface
instead of only in vnc_dpy_switch()

Signed-off-by: Daniel P. Berrange <address@hidden>
Reviewed-by: Peter Lieven <address@hidden>
Tested-by: Peter Lieven <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit b69a553b4af9bc87a8b2e0a7b7a7de4cc7f0557e)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 8e44714fe9f471474a439cafaaa386ffbddfa24a
      
https://github.com/qemu/qemu/commit/8e44714fe9f471474a439cafaaa386ffbddfa24a
  Author: Stefan Hajnoczi <address@hidden>
  Date:   2016-09-08 (Thu, 08 Sep 2016)

  Changed paths:
    M hw/virtio/virtio.c

  Log Message:
  -----------
  virtio: recalculate vq->inuse after migration

The vq->inuse field is not migrated.  Many devices don't hold
VirtQueueElements across migration so it doesn't matter that vq->inuse
starts at 0 on the destination QEMU.

At least virtio-serial, virtio-blk, and virtio-balloon migrate while
holding VirtQueueElements.  For these devices we need to recalculate
vq->inuse upon load so the value is correct.

Cc: address@hidden
Signed-off-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit bccdef6b1a204db0f41ffb6e24ce373e4d7890d4)
Signed-off-by: Michael Roth <address@hidden>


  Commit: ca86c04717c23b2155a9366522736995bc9bd772
      
https://github.com/qemu/qemu/commit/ca86c04717c23b2155a9366522736995bc9bd772
  Author: Stefan Hajnoczi <address@hidden>
  Date:   2016-09-08 (Thu, 08 Sep 2016)

  Changed paths:
    M hw/virtio/virtio.c

  Log Message:
  -----------
  virtio: decrement vq->inuse in virtqueue_discard()

virtqueue_discard() moves vq->last_avail_idx back so the element can be
popped again.  It's necessary to decrement vq->inuse to avoid "leaking"
the element count.

Cc: address@hidden
Signed-off-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 58a83c61496eeb0d31571a07a51bc1947e3379ac)
Signed-off-by: Michael Roth <address@hidden>


  Commit: f216833ac0fcd85f62d73387f529f141f8f4abfd
      
https://github.com/qemu/qemu/commit/f216833ac0fcd85f62d73387f529f141f8f4abfd
  Author: Vadim Rozenfeld <address@hidden>
  Date:   2016-09-08 (Thu, 08 Sep 2016)

  Changed paths:
    M block/iscsi.c

  Log Message:
  -----------
  iscsi: pass SCSI status back for SG_IO

Signed-off-by: Vadim Rozenfeld <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 644c6869d335e10bc10b8399646f767763c4977f)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 93060258ae748573ca7197204125a2670047896d
      
https://github.com/qemu/qemu/commit/93060258ae748573ca7197204125a2670047896d
  Author: Li Qiang <address@hidden>
  Date:   2016-09-08 (Thu, 08 Sep 2016)

  Changed paths:
    M hw/net/vmxnet_tx_pkt.c

  Log Message:
  -----------
  net: vmxnet: check IP header length

Vmxnet3 device emulator when parsing packet headers does not check
for IP header length. It could lead to a OOB access when reading
further packet data. Add check to avoid it.

Reported-by: Li Qiang <address@hidden>
Signed-off-by: Prasad J Pandit <address@hidden>
Reviewed-by: Dmitry Fleytman <address@hidden>
Signed-off-by: Michael Roth <address@hidden>


  Commit: cb3677cd50dcb07e74d0113337e40e9e3e14d728
      
https://github.com/qemu/qemu/commit/cb3677cd50dcb07e74d0113337e40e9e3e14d728
  Author: Li Qiang <address@hidden>
  Date:   2016-09-08 (Thu, 08 Sep 2016)

  Changed paths:
    M hw/net/vmxnet_tx_pkt.c

  Log Message:
  -----------
  net: vmxnet: use g_new for pkt initialisation

When vmxnet transport abstraction layer initialises pkt,
the maximum fragmentation count is not checked. This could lead
to an integer overflow causing a NULL pointer dereference.
Replace g_malloc() with g_new() to catch the multiplication
overflow.

Reported-by: Li Qiang <address@hidden>
Signed-off-by: Prasad J Pandit <address@hidden>
Acked-by: Dmitry Fleytman <address@hidden>
Signed-off-by: Michael Roth <address@hidden>


  Commit: 917e9a9816f34787391059c89ba5fb770fe22028
      
https://github.com/qemu/qemu/commit/917e9a9816f34787391059c89ba5fb770fe22028
  Author: Greg Kurz <address@hidden>
  Date:   2016-09-08 (Thu, 08 Sep 2016)

  Changed paths:
    M hw/9pfs/9p.c

  Log Message:
  -----------
  9pfs: forbid illegal path names

Empty path components don't make sense for most commands and may cause
undefined behavior, depending on the backend.

Also, the walk request described in the 9P spec [1] clearly shows that
the client is supposed to send individual path components: the official
linux client never sends portions of path containing the / character for
example.

Moreover, the 9P spec [2] also states that a system can decide to restrict
the set of supported characters used in path components, with an explicit
mention "to remove slashes from name components".

This patch introduces a new name_is_illegal() helper that checks the
names sent by the client are not empty and don't contain unwanted chars.
Since 9pfs is only supported on linux hosts, only the / character is
checked at the moment. When support for other hosts (AKA. win32) is added,
other chars may need to be blacklisted as well.

If a client sends an illegal path component, the request will fail and
ENOENT is returned to the client.

[1] http://man.cat-v.org/plan_9/5/walk
[2] http://man.cat-v.org/plan_9/5/intro

Suggested-by: Peter Maydell <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit fff39a7ad09da07ef490de05c92c91f22f8002f2)
Signed-off-by: Michael Roth <address@hidden>


  Commit: b5191b2df7dc92a7a4f7fb4d18c37cf8aae38894
      
https://github.com/qemu/qemu/commit/b5191b2df7dc92a7a4f7fb4d18c37cf8aae38894
  Author: Greg Kurz <address@hidden>
  Date:   2016-09-08 (Thu, 08 Sep 2016)

  Changed paths:
    M hw/9pfs/9p.c

  Log Message:
  -----------
  9pfs: forbid . and .. in file names

According to the 9P spec http://man.cat-v.org/plan_9/5/open about the
create request:

The names . and .. are special; it is illegal to create files with these
names.

This patch causes the create and lcreate requests to fail with EINVAL if
the file name is either "." or "..".

Even if it isn't explicitly written in the spec, this patch extends the
checking to all requests that may cause a directory entry to be created:

    - mknod
    - rename
    - renameat
    - mkdir
    - link
    - symlink

The unlinkat request also gets patched for consistency (even if
rmdir("foo/..") is expected to fail according to POSIX.1-2001).

The various error values come from the linux manual pages.

Suggested-by: Peter Maydell <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit 805b5d98c649d26fc44d2d7755a97f18e62b438a)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 85d0a53c583656e5e37a8317f9119933c796847f
      
https://github.com/qemu/qemu/commit/85d0a53c583656e5e37a8317f9119933c796847f
  Author: Greg Kurz <address@hidden>
  Date:   2016-09-08 (Thu, 08 Sep 2016)

  Changed paths:
    M hw/9pfs/9p.c
    M hw/9pfs/9p.h

  Log Message:
  -----------
  9pfs: handle walk of ".." in the root directory

The 9P spec at http://man.cat-v.org/plan_9/5/intro says:

All directories must support walks to the directory .. (dot-dot) meaning
parent directory, although by convention directories contain no explicit
entry for .. or . (dot).  The parent of the root directory of a server's
tree is itself.

This means that a client cannot walk further than the root directory
exported by the server. In other words, if the client wants to walk
"/.." or "/foo/../..", the server should answer like the request was
to walk "/".

This patch just does that:
- we cache the QID of the root directory at attach time
- during the walk we compare the QID of each path component with the root
  QID to detect if we're in a "/.." situation
- if so, we skip the current component and go to the next one

Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit 56f101ecce0eafd09e2daf1c4eeb1377d6959261)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 1af2c3fcb89969f0fc5e31d6e50561a770c9fa8a
      
https://github.com/qemu/qemu/commit/1af2c3fcb89969f0fc5e31d6e50561a770c9fa8a
  Author: Stefan Hajnoczi <address@hidden>
  Date:   2016-09-14 (Wed, 14 Sep 2016)

  Changed paths:
    M hw/virtio/virtio.c

  Log Message:
  -----------
  virtio: zero vq->inuse in virtio_reset()

vq->inuse must be zeroed upon device reset like most other virtqueue
fields.

In theory, virtio_reset() just needs assert(vq->inuse == 0) since
devices must clean up in-flight requests during reset (requests cannot
not be leaked!).

In practice, it is difficult to achieve vq->inuse == 0 across reset
because balloon, blk, 9p, etc implement various different strategies for
cleaning up requests.  Most devices call g_free(elem) directly without
telling virtio.c that the VirtQueueElement is cleaned up.  Therefore
vq->inuse is not decremented during reset.

This patch zeroes vq->inuse and trusts that devices are not leaking
VirtQueueElements across reset.

I will send a follow-up series that refactors request life-cycle across
all devices and converts vq->inuse = 0 into assert(vq->inuse == 0) but
this more invasive approach is not appropriate for stable trees.

Signed-off-by: Stefan Hajnoczi <address@hidden>
Cc: qemu-stable <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Ladi Prosek <address@hidden>
(cherry picked from commit 4b7f91ed0270a371e1933efa21ba600b6da23ab9)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 44d28f22bcc687f75849c9fa07ce88c5d8cefa3b
      
https://github.com/qemu/qemu/commit/44d28f22bcc687f75849c9fa07ce88c5d8cefa3b
  Author: Ladi Prosek <address@hidden>
  Date:   2016-09-14 (Wed, 14 Sep 2016)

  Changed paths:
    M hw/virtio/virtio-balloon.c

  Log Message:
  -----------
  virtio-balloon: discard virtqueue element on reset

The one pending element is being freed but not discarded on device
reset, which causes svq->inuse to creep up, eventually hitting the
"Virtqueue size exceeded" error.

Properly discarding the element on device reset makes sure that its
buffers are unmapped and the inuse counter stays balanced.

Cc: Michael S. Tsirkin <address@hidden>
Cc: Roman Kagan <address@hidden>
Cc: Stefan Hajnoczi <address@hidden>
Signed-off-by: Ladi Prosek <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 104e70cae78bd4afd95d948c6aff188f10508a9c)
Signed-off-by: Michael Roth <address@hidden>


  Commit: b9ab2f66716ad5bf18797e6844f6969e9a868633
      
https://github.com/qemu/qemu/commit/b9ab2f66716ad5bf18797e6844f6969e9a868633
  Author: Gonglei <address@hidden>
  Date:   2016-09-20 (Tue, 20 Sep 2016)

  Changed paths:
    M ui/vnc.c

  Log Message:
  -----------
  vnc: fix qemu crash because of SIGSEGV

The backtrace is:

0x00007f0b75cdf880 in pixman_image_get_stride () from /lib64/libpixman-1.so.0
0x00007f0b77bcb3cf in vnc_server_fb_stride (vd=0x7f0b7a1a2bb0) at ui/vnc.c:680
vnc_dpy_copy (dcl=0x7f0b7a1a2c00, src_x=224, src_y=263, dst_x=319, dst_y=363, 
w=1, h=1) at ui/vnc.c:915
0x00007f0b77bbcc35 in dpy_gfx_copy (con=0x7f0b7a146210, address@hidden, 
address@hidden, address@hidden,
address@hidden, w=1, h=1) at ui/console.c:1575
0x00007f0b77bbda4e in qemu_console_copy (con=<optimized out>, address@hidden, 
address@hidden, address@hidden,
address@hidden, w=<optimized out>, h=<optimized out>) at ui/console.c:2111
0x00007f0b77ac0980 in cirrus_do_copy (h=<optimized out>, w=<optimized out>, 
src=<optimized out>, dst=<optimized out>, s=0x7f0b7b086090) at 
hw/display/cirrus_vga.c:774
cirrus_bitblt_videotovideo_copy (s=0x7f0b7b086090) at 
hw/display/cirrus_vga.c:793
cirrus_bitblt_videotovideo (s=0x7f0b7b086090) at hw/display/cirrus_vga.c:915
cirrus_bitblt_start (s=0x7f0b7b086090) at hw/display/cirrus_vga.c:1056
0x00007f0b77965cfb in memory_region_write_accessor (mr=0x7f0b7b096e40, 
addr=320, value=<optimized out>, size=1, shift=<optimized out>,mask=<optimized 
out>, attrs=...) at /root/rpmbuild/BUILD/master/qemu/memory.c:525
0x00007f0b77963f59 in access_with_adjusted_size (address@hidden, 
address@hidden, address@hidden,
access_size_min=<optimized out>, access_size_max=<optimized out>, 
address@hidden <memory_region_write_accessor>,
address@hidden, address@hidden) at /root/rpmbuild/BUILD/master/qemu/memory.c:591
0x00007f0b77968315 in memory_region_dispatch_write (address@hidden, 
address@hidden, data=18446744073709551362,
address@hidden, address@hidden) at 
/root/rpmbuild/BUILD/master/qemu/memory.c:1262
0x00007f0b779256a9 in address_space_write_continue (mr=0x7f0b7b096e40, l=4, 
addr1=320, len=4, buf=0x7f0b77713028 "\002\377\377\377",
attrs=..., addr=4273930560, as=0x7f0b7827d280 <address_space_memory>) at 
/root/rpmbuild/BUILD/master/qemu/exec.c:2544
address_space_write (as=<optimized out>, addr=<optimized out>, attrs=..., 
buf=<optimized out>, len=<optimized out>) at 
/root/rpmbuild/BUILD/master/qemu/exec.c:2601
0x00007f0b77925c1d in address_space_rw (as=<optimized out>, addr=<optimized 
out>, attrs=..., address@hidden,
address@hidden "\002\377\377\377", len=<optimized out>, is_write=<optimized 
out>) at /root/rpmbuild/BUILD/master/qemu/exec.c:2703
0x00007f0b77962f53 in kvm_cpu_exec (address@hidden) at 
/root/rpmbuild/BUILD/master/qemu/kvm-all.c:1965
0x00007f0b77950cc6 in qemu_kvm_cpu_thread_fn (arg=0x7f0b79fcc2d0) at 
/root/rpmbuild/BUILD/master/qemu/cpus.c:1078
0x00007f0b744b3dc5 in start_thread (arg=0x7f0b69a27700) at pthread_create.c:308
0x00007f0b70d3d66d in clone () from /lib64/libc.so.6

The code path while meeting segfault:
 vnc_dpy_copy
   vnc_update_client
     vnc_disconnect_finish [while vnc_disconnect_start() is invoked because 
somethins wrong]
       vnc_update_server_surface
   vd->server = NULL;
   vnc_server_fb_stride
     pixman_image_get_stride(vd->server)

Let's add a non-NULL check before calling vnc_server_fb_stride() to avoid 
segmentation fault.

Cc: Gerd Hoffmann <address@hidden>
Cc: Daniel P. Berrange <address@hidden>
Reported-by: Yanying Zhuang <address@hidden>
Signed-off-by: Gonglei <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 3e10c3ecfcaf604d8b400d6e463e1a186ce97d9b)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 5e2c6fe7cc5314c13d96069328b603c40dc12b41
      
https://github.com/qemu/qemu/commit/5e2c6fe7cc5314c13d96069328b603c40dc12b41
  Author: Greg Kurz <address@hidden>
  Date:   2016-09-20 (Tue, 20 Sep 2016)

  Changed paths:
    M hw/9pfs/9p.c

  Log Message:
  -----------
  9pfs: fix potential segfault during walk

If the call to fid_to_qid() returns an error, we will call v9fs_path_free()
on uninitialized paths.

It is a regression introduced by the following commit:

56f101ecce0e 9pfs: handle walk of ".." in the root directory

Let's fix this by initializing dpath and path before calling fid_to_qid().

Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Cédric Le Goater <address@hidden>
[groug: updated the changelog to indicate this is regression and to provide
  the offending commit SHA1]
Signed-off-by: Greg Kurz <address@hidden>

(cherry picked from commit 13fd08e631ec0c3ff5ad1bdcb6a4474c7d9a024f)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 12be5cfe1cfe22829e06270d70a15c477f0d1712
      
https://github.com/qemu/qemu/commit/12be5cfe1cfe22829e06270d70a15c477f0d1712
  Author: Li Qiang <address@hidden>
  Date:   2016-09-20 (Tue, 20 Sep 2016)

  Changed paths:
    M hw/scsi/mptsas.c

  Log Message:
  -----------
  scsi: mptsas: use g_new0 to allocate MPTSASRequest object

When processing IO request in mptsas, it uses g_new to allocate
a 'req' object. If an error occurs before 'req->sreq' is
allocated, It could lead to an OOB write in mptsas_free_request
function. Use g_new0 to avoid it.

Reported-by: Li Qiang <address@hidden>
Signed-off-by: Prasad J Pandit <address@hidden>
Message-Id: <address@hidden>
Cc: address@hidden
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 670e56d3ed2918b3861d9216f2c0540d9e9ae0d5)
Signed-off-by: Michael Roth <address@hidden>


  Commit: c5b64fb79c8e265c4ff7ab3ff94a8991b8e3fdc0
      
https://github.com/qemu/qemu/commit/c5b64fb79c8e265c4ff7ab3ff94a8991b8e3fdc0
  Author: Prasad J Pandit <address@hidden>
  Date:   2016-09-20 (Tue, 20 Sep 2016)

  Changed paths:
    M hw/scsi/vmw_pvscsi.c

  Log Message:
  -----------
  scsi: pvscsi: limit process IO loop to ring size

Vmware Paravirtual SCSI emulator while processing IO requests
could run into an infinite loop if 'pvscsi_ring_pop_req_descr'
always returned positive value. Limit IO loop to the ring size.

Cc: address@hidden
Reported-by: Li Qiang <address@hidden>
Signed-off-by: Prasad J Pandit <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit d251157ac1928191af851d199a9ff255d330bec9)
Signed-off-by: Michael Roth <address@hidden>


  Commit: b79239a41bffffbbe4ed412acd191c75ef605cc0
      
https://github.com/qemu/qemu/commit/b79239a41bffffbbe4ed412acd191c75ef605cc0
  Author: Lin Ma <address@hidden>
  Date:   2016-09-20 (Tue, 20 Sep 2016)

  Changed paths:
    M qemu-char.c

  Log Message:
  -----------
  qemu-char: avoid segfault if user lacks of permisson of a given logfile

Function qemu_chr_alloc returns NULL if it failed to open logfile by any reason,
says no write permission. For backends tty, stdio and msmouse, They need to
check this return value to avoid segfault in this case.

Signed-off-by: Lin Ma <address@hidden>
Cc: qemu-stable <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 71200fb9664c2967a1cdd22b68b0da3a8b2b3eb7)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 7aa7c25186fc0cf9d9dd3edf88c8f15deeec3c00
      
https://github.com/qemu/qemu/commit/7aa7c25186fc0cf9d9dd3edf88c8f15deeec3c00
  Author: Rony Weng <address@hidden>
  Date:   2016-09-20 (Tue, 20 Sep 2016)

  Changed paths:
    M hw/scsi/scsi-disk.c

  Log Message:
  -----------
  scsi-disk: change disk serial length from 20 to 36

Openstack Cinder assigns volume a 36 characters uuid as serial.
QEMU will shrinks the uuid to 20 characters, which does not match
the original uuid.

Note that there is no limit to the length of the serial number in
the SCSI spec.  20 was copy-pasted from virtio-blk which in turn was
copy-pasted from ATA; 36 is even more arbitrary.  However, bumping it
up too much might cause issues (e.g. 252 seems to make sense because
then the maximum amount of returned data is 256; but who knows there's
no off-by-one somewhere for such a nicely rounded number).

Signed-off-by: Rony Weng <address@hidden>
Message-Id: <address@hidden>
Cc: address@hidden
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 48b6206305b8d56524ac2ee347b68e6e0a528559)
Signed-off-by: Michael Roth <address@hidden>


  Commit: da99530e410349d672e792e820b355a648d430fa
      
https://github.com/qemu/qemu/commit/da99530e410349d672e792e820b355a648d430fa
  Author: Prasad J Pandit <address@hidden>
  Date:   2016-09-20 (Tue, 20 Sep 2016)

  Changed paths:
    M hw/scsi/vmw_pvscsi.c

  Log Message:
  -----------
  vmw_pvscsi: check page count while initialising descriptor rings

Vmware Paravirtual SCSI emulation uses command descriptors to
process SCSI commands. These descriptors come with their ring
buffers. A guest could set the page count for these rings to
an arbitrary value, leading to infinite loop or OOB access.
Add check to avoid it.

Reported-by: Tom Victor <address@hidden>
Signed-off-by: Prasad J Pandit <address@hidden>
Message-Id: <address@hidden>
Cc: address@hidden
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 7f61f4690dd153be98900a2a508b88989e692753)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 5e39560941f6b3ee61ea24c7a34e8fcf9e291fca
      
https://github.com/qemu/qemu/commit/5e39560941f6b3ee61ea24c7a34e8fcf9e291fca
  Author: Prasad J Pandit <address@hidden>
  Date:   2016-09-20 (Tue, 20 Sep 2016)

  Changed paths:
    M hw/scsi/mptconfig.c

  Log Message:
  -----------
  scsi: mptconfig: fix an assert expression

When LSI SAS1068 Host Bus emulator builds configuration page
headers, mptsas_config_pack() should assert that the size
fits in a byte.  However, the size is expressed in 32-bit
units, so up to 1020 bytes fit.  The assertion was only
allowing replies up to 252 bytes, so fix it.

Suggested-by: Paolo Bonzini <address@hidden>
Signed-off-by: Prasad J Pandit <address@hidden>
Message-Id: <address@hidden>
Cc: address@hidden
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit cf2bce203a45d7437029d108357fb23fea0967b6)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 0751a606c2be849cb9763f7c88578210d75884f3
      
https://github.com/qemu/qemu/commit/0751a606c2be849cb9763f7c88578210d75884f3
  Author: Paolo Bonzini <address@hidden>
  Date:   2016-09-20 (Tue, 20 Sep 2016)

  Changed paths:
    M hw/scsi/mptconfig.c

  Log Message:
  -----------
  scsi: mptconfig: fix misuse of MPTSAS_CONFIG_PACK

These issues cause respectively a QEMU crash and a leak of 2 bytes of
stack.  They were discovered by VictorV of 360 Marvel Team.

Reported-by: Tom Victor <address@hidden>
Cc: address@hidden
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 65a8e1f6413a0f6f79894da710b5d6d43361d27d)
Signed-off-by: Michael Roth <address@hidden>


  Commit: d90481343f93581ab6f3415ee35663cc8f2da1f5
      
https://github.com/qemu/qemu/commit/d90481343f93581ab6f3415ee35663cc8f2da1f5
  Author: Daniel P. Berrange <address@hidden>
  Date:   2016-09-20 (Tue, 20 Sep 2016)

  Changed paths:
    M crypto/cipher-gcrypt.c
    M crypto/cipher-nettle.c
    M tests/test-crypto-cipher.c

  Log Message:
  -----------
  crypto: ensure XTS is only used with ciphers with 16 byte blocks

The XTS cipher mode needs to be used with a cipher which has
a block size of 16 bytes. If a mis-matching block size is used,
the code will either corrupt memory beyond the IV array, or
not fully encrypt/decrypt the IV.

This fixes a memory corruption crash when attempting to use
cast5-128 with xts, since the former has an 8 byte block size.

A test case is added to ensure the cipher creation fails with
such an invalid combination.

Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Daniel P. Berrange <address@hidden>
(cherry picked from commit a5d2f44d0d3e7523670e103a8c37faed29ff2b76)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 12664c5a1c1d9e75c36db2bde258c69c25d6c1ff
      
https://github.com/qemu/qemu/commit/12664c5a1c1d9e75c36db2bde258c69c25d6c1ff
  Author: Fam Zheng <address@hidden>
  Date:   2016-09-20 (Tue, 20 Sep 2016)

  Changed paths:
    M include/sysemu/iothread.h
    M iothread.c
    M vl.c

  Log Message:
  -----------
  iothread: Stop threads before main() quits

Right after main_loop ends, we release various things but keep iothread
alive. The latter is not prepared to the sudden change of resources.

Specifically, after bdrv_close_all(), virtio-scsi dataplane get a
surprise at the empty BlockBackend:

(gdb) bt
    at /usr/src/debug/qemu-2.6.0/hw/scsi/virtio-scsi.c:543
    at /usr/src/debug/qemu-2.6.0/hw/scsi/virtio-scsi.c:577

It is because the d->conf.blk->root is set to NULL, then
blk_get_aio_context() returns qemu_aio_context, whereas s->ctx is still
pointing to the iothread:

    hw/scsi/virtio-scsi.c:543:

    if (s->dataplane_started) {
  assert(blk_get_aio_context(d->conf.blk) == s->ctx);
    }

To fix this, let's stop iothreads before doing bdrv_close_all().

Cc: address@hidden
Signed-off-by: Fam Zheng <address@hidden>
Reviewed-by: Paolo Bonzini <address@hidden>
Message-id: address@hidden
Signed-off-by: Stefan Hajnoczi <address@hidden>
(cherry picked from commit dce8921b2baaf95974af8176406881872067adfa)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 469513b38a7ffabea941b607b44f1d9b3d4da3ef
      
https://github.com/qemu/qemu/commit/469513b38a7ffabea941b607b44f1d9b3d4da3ef
  Author: Fam Zheng <address@hidden>
  Date:   2016-09-20 (Tue, 20 Sep 2016)

  Changed paths:
    M hw/scsi/scsi-disk.c

  Log Message:
  -----------
  scsi-disk: Cleaning up around tray open state

Even if tray is not open, it can be empty (blk_is_inserted() == false).
Handle both cases correctly by replacing the s->tray_open checks with
blk_is_available(), which is an AND of the two.

Also simplify successive checks of them into blk_is_available(), in a
couple cases.

Signed-off-by: Fam Zheng <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit cd723b85601baa7a0eeffbac83421357a70d81ee)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 6e184753b3c1ba10e4b552805cb00ec8c51560b0
      
https://github.com/qemu/qemu/commit/6e184753b3c1ba10e4b552805cb00ec8c51560b0
  Author: Fam Zheng <address@hidden>
  Date:   2016-09-20 (Tue, 20 Sep 2016)

  Changed paths:
    M hw/scsi/virtio-scsi.c

  Log Message:
  -----------
  virtio-scsi: Don't abort when media is ejected

With an ejected block backend, blk_get_aio_context() would return
qemu_aio_context. In this case don't assert.

Signed-off-by: Fam Zheng <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 2a2d69f490c1b1dc6b6d2aef385ee7b654497a77)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 2b13613e02e145440f86e05124d574fd2c2afa0a
      
https://github.com/qemu/qemu/commit/2b13613e02e145440f86e05124d574fd2c2afa0a
  Author: Daniel P. Berrange <address@hidden>
  Date:   2016-09-28 (Wed, 28 Sep 2016)

  Changed paths:
    M ui/vnc.c

  Log Message:
  -----------
  ui: avoid crash if vnc client disconnects with writes pending

The vnc_client_read() function is called from the vnc_client_io()
event handler callback when there is incoming data to process.
If it detects that the client has disconnected, then it will
trigger cleanup and free'ing of the VncState client struct at
a safe time.

Unfortunately, the vnc_client_io() event handler will also call
vnc_client_write() to handle any outgoing data writes. So if
vnc_client_io() was invoked with both G_IO_IN and G_IO_OUT
events set, and the client disconnects, we may try to write to
a client which has just been freed.

https://bugs.launchpad.net/qemu/+bug/1594861

Signed-off-by: Daniel P. Berrange <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit ea697449884d83b83fefbc9cd87bdde0c94b49d6)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 6be9ee16201f300973449ea355456e3e942f14f4
      
https://github.com/qemu/qemu/commit/6be9ee16201f300973449ea355456e3e942f14f4
  Author: Daniel P. Berrange <address@hidden>
  Date:   2016-09-28 (Wed, 28 Sep 2016)

  Changed paths:
    M ui/vnc.c

  Log Message:
  -----------
  vnc: fix crash when vnc_server_info_get has an error

The vnc_server_info_get will allocate the VncServerInfo
struct and then call vnc_init_basic_info_from_server_addr
to populate the basic fields. If this returns an error
though, the qapi_free_VncServerInfo call will then crash
because the VncServerInfo struct instance was not properly
NULL-initialized and thus contains random stack garbage.

 #0  0x00007f1987c8e6f5 in raise () at /lib64/libc.so.6
 #1  0x00007f1987c902fa in abort () at /lib64/libc.so.6
 #2  0x00007f1987ccf600 in __libc_message () at /lib64/libc.so.6
 #3  0x00007f1987cd7d4a in _int_free () at /lib64/libc.so.6
 #4  0x00007f1987cdb2ac in free () at /lib64/libc.so.6
 #5  0x00007f198b654f6e in g_free () at /lib64/libglib-2.0.so.0
 #6  0x0000559193cdcf54 in visit_type_str (address@hidden
     0x5591972f14b0, address@hidden "host", address@hidden, address@hidden)
     at qapi/qapi-visit-core.c:255
 #7  0x0000559193cca8f3 in visit_type_VncBasicInfo_members (address@hidden
     0x5591972f14b0, address@hidden, address@hidden) at qapi-visit.c:12307
 #8  0x0000559193ccb523 in visit_type_VncServerInfo_members (address@hidden
     0x5591972f14b0, obj=0x5591961dbfa0, address@hidden) at qapi-visit.c:12632
 #9  0x0000559193ccb60b in visit_type_VncServerInfo (address@hidden
     0x5591972f14b0, address@hidden, address@hidden, address@hidden) at 
qapi-visit.c:12658
 #10 0x0000559193cb53d8 in qapi_free_VncServerInfo (obj=<optimized out>) at 
qapi-types.c:3970
 #11 0x0000559193c1e6ba in vnc_server_info_get (vd=0x7f1951498010) at 
ui/vnc.c:233
 #12 0x0000559193c24275 in vnc_connect (vs=0x559197b2f200, vs=0x559197b2f200, 
event=QAPI_EVENT_VNC_CONNECTED) at ui/vnc.c:284
 #13 0x0000559193c24275 in vnc_connect (address@hidden, address@hidden, 
address@hidden e, address@hidden) at ui/vnc.c:3039
 #14 0x0000559193c25806 in vnc_display_add_client (id=<optimized out>, 
csock=<optimized out>, skipauth=<optimized out>)
     at ui/vnc.c:3877
 #15 0x0000559193a90c28 in qmp_marshal_add_client (args=<optimized out>, 
ret=<optimized out>, errp=0x7fffd7899f90)
     at qmp-marshal.c:105
 #16 0x000055919399c2b7 in handle_qmp_command (parser=<optimized out>, 
tokens=<optimized out>)
     at /home/berrange/src/virt/qemu/monitor.c:3971
 #17 0x0000559193ce3307 in json_message_process_token (lexer=0x559194ab0838, 
input=0x559194a6d940, type=JSON_RCURLY, x=111, y=1 2) at 
qobject/json-streamer.c:105
 #18 0x0000559193cfa90d in json_lexer_feed_char (address@hidden, ch=125 '}', 
address@hidden)
     at qobject/json-lexer.c:319
 #19 0x0000559193cfaa1e in json_lexer_feed (lexer=0x559194ab0838, 
buffer=<optimized out>, size=<optimized out>)
     at qobject/json-lexer.c:369
 #20 0x0000559193ce33c9 in json_message_parser_feed (parser=<optimized out>, 
buffer=<optimized out>, size=<optimized out>)
     at qobject/json-streamer.c:124
 #21 0x000055919399a85b in monitor_qmp_read (opaque=<optimized out>, 
buf=<optimized out>, size=<optimized out>)
     at /home/berrange/src/virt/qemu/monitor.c:3987
 #22 0x0000559193a87d00 in tcp_chr_read (chan=<optimized out>, cond=<optimized 
out>, opaque=0x559194a7d900)
     at qemu-char.c:2895
 #23 0x00007f198b64f703 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
 #24 0x0000559193c484b3 in main_loop_wait () at main-loop.c:213
 #25 0x0000559193c484b3 in main_loop_wait (timeout=<optimized out>) at 
main-loop.c:258
 #26 0x0000559193c484b3 in main_loop_wait (nonblocking=<optimized out>) at 
main-loop.c:506
 #27 0x0000559193964c55 in main () at vl.c:1908
 #28 0x0000559193964c55 in main (argc=<optimized out>, argv=<optimized out>, 
envp=<optimized out>) at vl.c:4603

This was introduced in

  commit 98481bfcd661daa3c160cc87a297b0e60a307788
  Author: Eric Blake <address@hidden>
  Date:   Mon Oct 26 16:34:45 2015 -0600

    vnc: Hoist allocation of VncBasicInfo to callers

which added error reporting for vnc_init_basic_info_from_server_addr
but didn't change the g_malloc calls to g_malloc0.

Signed-off-by: Daniel P. Berrange <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 3e7f136d8b4383d99f1b034a045b73f9b12a4eae)
Signed-off-by: Michael Roth <address@hidden>


  Commit: c5518b3a264f3f01bc93316a5039a53b6c436b6d
      
https://github.com/qemu/qemu/commit/c5518b3a264f3f01bc93316a5039a53b6c436b6d
  Author: Daniel P. Berrange <address@hidden>
  Date:   2016-09-28 (Wed, 28 Sep 2016)

  Changed paths:
    M ui/vnc.c

  Log Message:
  -----------
  vnc: ensure connection sharing/limits is always configured

The connection sharing / limits are only set in the
vnc_display_open() method and so missed when VNC is running
with '-vnc none'. This in turn prevents clients being added
to the VNC server with the QMP "add_client" command.

This was introduced in

  commit e5f34cdd2da54f28d90889a3afd15fad2d6105ff
  Author: Gerd Hoffmann <address@hidden>
  Date:   Thu Oct 2 12:09:34 2014 +0200

      vnc: track & limit connections

Signed-off-by: Daniel P. Berrange <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 12e29b1682e0a50ed57c324152addb585ae5ce69)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 14713d60cb339d95776771a46037a156084091d0
      
https://github.com/qemu/qemu/commit/14713d60cb339d95776771a46037a156084091d0
  Author: Daniel P. Berrange <address@hidden>
  Date:   2016-09-28 (Wed, 28 Sep 2016)

  Changed paths:
    M ui/vnc.c

  Log Message:
  -----------
  vnc: don't crash getting server info if lsock is NULL

When VNC is started with '-vnc none' there will be no
listener socket present. When we try to populate the
VncServerInfo we'll crash accessing a NULL 'lsock'
field.

 #0  qio_channel_socket_get_local_address (ioc=0x0, address@hidden) at 
io/channel-socket.c:33
 #1  0x00007f4b9a297d6f in vnc_init_basic_info_from_server_addr 
(errp=0x7ffd5b8aa0f0, info=0x7f4b9d425460, ioc=<optimized out>)  at ui/vnc.c:146
 #2  vnc_server_info_get (vd=0x7f4b9e858000) at ui/vnc.c:223
 #3  0x00007f4b9a29d318 in vnc_qmp_event (vs=0x7f4b9ef82000, vs=0x7f4b9ef82000, 
event=QAPI_EVENT_VNC_CONNECTED) at ui/vnc.c:279
 #4  vnc_connect (address@hidden, address@hidden, address@hidden, 
websocket=websocket @entry=false) at ui/vnc.c:2994
 #5  0x00007f4b9a29e8c8 in vnc_display_add_client (id=<optimized out>, 
csock=<optimized out>, skipauth=<optimized out>) at ui/v nc.c:3825
 #6  0x00007f4b9a18d8a1 in qmp_marshal_add_client (args=<optimized out>, 
ret=<optimized out>, errp=0x7ffd5b8aa230) at qmp-marsh al.c:123
 #7  0x00007f4b9a0b53f5 in handle_qmp_command (parser=<optimized out>, 
tokens=<optimized out>) at /usr/src/debug/qemu-2.6.0/mon itor.c:3922
 #8  0x00007f4b9a348580 in json_message_process_token (lexer=0x7f4b9c78dfe8, 
input=0x7f4b9c7350e0, type=JSON_RCURLY, x=111, y=5 9) at 
qobject/json-streamer.c:94
 #9  0x00007f4b9a35cfeb in json_lexer_feed_char (address@hidden, ch=125 '}', 
address@hidden) at qobj ect/json-lexer.c:310
 #10 0x00007f4b9a35d0ae in json_lexer_feed (lexer=0x7f4b9c78dfe8, 
buffer=<optimized out>, size=<optimized out>) at qobject/json -lexer.c:360
 #11 0x00007f4b9a348679 in json_message_parser_feed (parser=<optimized out>, 
buffer=<optimized out>, size=<optimized out>) at q object/json-streamer.c:114
 #12 0x00007f4b9a0b3a1b in monitor_qmp_read (opaque=<optimized out>, 
buf=<optimized out>, size=<optimized out>) at /usr/src/deb 
ug/qemu-2.6.0/monitor.c:3938
 #13 0x00007f4b9a186751 in tcp_chr_read (chan=<optimized out>, cond=<optimized 
out>, opaque=0x7f4b9c7add40) at qemu-char.c:2895
 #14 0x00007f4b92b5c79a in g_main_context_dispatch () from 
/lib64/libglib-2.0.so.0
 #15 0x00007f4b9a2bb0c0 in glib_pollfds_poll () at main-loop.c:213
 #16 os_host_main_loop_wait (timeout=<optimized out>) at main-loop.c:258
 #17 main_loop_wait (nonblocking=<optimized out>) at main-loop.c:506
 #18 0x00007f4b9a0835cf in main_loop () at vl.c:1934
 #19 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at 
vl.c:4667

Do an upfront check for a NULL lsock and report an error to
the caller, which matches behaviour from before

  commit 04d2529da27db512dcbd5e99d0e26d333f16efcc
  Author: Daniel P. Berrange <address@hidden>
  Date:   Fri Feb 27 16:20:57 2015 +0000

    ui: convert VNC server to use QIOChannelSocket

where getsockname() would be given a FD value -1 and thus report
an error to the caller.

Signed-off-by: Daniel P. Berrange <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 624cdd46d7f67fa2d23e87ffe0a36a569edde11a)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 8ef7abeccf527029c3b2e70ec585f1788fa2e007
      
https://github.com/qemu/qemu/commit/8ef7abeccf527029c3b2e70ec585f1788fa2e007
  Author: Gerd Hoffmann <address@hidden>
  Date:   2016-09-28 (Wed, 28 Sep 2016)

  Changed paths:
    M ui/vnc.c

  Log Message:
  -----------
  vnc: make sure we finish disconnect

It may happen that vnc connections linger in disconnecting state forever
because VncState happens to be in a state where vnc_update_client()
exists early and never reaches the vnc_disconnect_finish() call at the
bottom of the function.  Fix that by doing an additinal check at the
start of the function.

https://bugzilla.redhat.com/show_bug.cgi?id=1352799

Signed-off-by: Gerd Hoffmann <address@hidden>
Message-id: address@hidden
(cherry picked from commit 5a8be0f73d6f60ff08746377eb09ca459f39deab)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 98b81297bfa7a1a7acfd8689f7c6447cbc128bfa
      
https://github.com/qemu/qemu/commit/98b81297bfa7a1a7acfd8689f7c6447cbc128bfa
  Author: Herongguang (Stephen) <address@hidden>
  Date:   2016-09-28 (Wed, 28 Sep 2016)

  Changed paths:
    M ui/vnc-enc-tight.c

  Log Message:
  -----------
  vnc-enc-tight: fix off-by-one bug

In tight_encode_indexed_rect32, buf(or src)’s size is count. In for loop,
the logic is supposed to be that i is an index into src, i should be
incremented when incrementing src.

This is broken when src is incremented but i is not before while loop,
resulting in off-by-one bug in while loop.

Signed-off-by: He Rongguang <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 3f7e51bca3ef2d64c53b35ab9916c99e4a9e3c69)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 1c57ced0c47f2df8fc06b2f697a399074d715f94
      
https://github.com/qemu/qemu/commit/1c57ced0c47f2df8fc06b2f697a399074d715f94
  Author: Gonglei <address@hidden>
  Date:   2016-09-28 (Wed, 28 Sep 2016)

  Changed paths:
    M ui/vnc.c

  Log Message:
  -----------
  vnc: fix incorrect checking condition when updating client

vs->disconnecting is set to TRUE and vs->ioc is closed, but
vs->ioc isn't set to NULL, so that the vnc_disconnect_finish()
isn't invoked when you update client in vnc_update_client()
after vnc_disconnect_start invoked. Let's using change the checking
condition to avoid resource leak.

Signed-off-by: Haibin Wang <address@hidden>
Signed-off-by: Gonglei <address@hidden>
Reviewed-by: Daniel P. Berrange <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 5a693efda84d7df5136cc2bd31c959bb1530b0c9)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 9ea7a46e2674edc84f056fc66c6f642d88b0c9ee
      
https://github.com/qemu/qemu/commit/9ea7a46e2674edc84f056fc66c6f642d88b0c9ee
  Author: John Snow <address@hidden>
  Date:   2016-09-28 (Wed, 28 Sep 2016)

  Changed paths:
    M hw/ide/ahci.c

  Log Message:
  -----------
  ahci: clear aiocb in ncq_cb

Similar to existing fixes for IDE (87ac25fd) and ATAPI (7f951b2d), the
AIOCB must be cleared in the callback. Otherwise, we may accidentally
try to reset a dangling pointer in bdrv_aio_cancel() from a port reset.

Signed-off-by: John Snow <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Message-id: address@hidden
Signed-off-by: John Snow <address@hidden>
Signed-off-by: Michael Roth <address@hidden>


  Commit: 1b5520a3fd6d7416bb7dff9b69c58fb83e23ed05
      
https://github.com/qemu/qemu/commit/1b5520a3fd6d7416bb7dff9b69c58fb83e23ed05
  Author: Cornelia Huck <address@hidden>
  Date:   2016-09-28 (Wed, 28 Sep 2016)

  Changed paths:
    M hw/s390x/css.c
    M hw/s390x/css.h

  Log Message:
  -----------
  s390x/css: handle cssid 255 correctly

The cssid 255 is reserved but still valid from an architectural
point of view. However, feeding a bogus schid of 0xffffffff into
the virtio hypercall will lead to a crash:

Stack trace of thread 138363:
  #0  0x00000000100d168c css_find_subch (qemu-system-s390x)
  #1  0x00000000100d3290 virtio_ccw_hcall_notify
  #2  0x00000000100cbf60 s390_virtio_hypercall
  #3  0x000000001010ff7a handle_hypercall
  #4  0x0000000010079ed4 kvm_cpu_exec (qemu-system-s390x)
  #5  0x00000000100609b4 qemu_kvm_cpu_thread_fn
  #6  0x000003ff8b887bb4 start_thread (libpthread.so.0)
  #7  0x000003ff8b78df0a thread_start (libc.so.6)

This is because the css array was only allocated for 0..254
instead of 0..255.

Let's fix this by bumping MAX_CSSID to 255 and fencing off the
reserved cssid of 255 during css image allocation.

Reported-by: Christian Borntraeger <address@hidden>
Tested-by: Christian Borntraeger <address@hidden>
Cc: address@hidden
Signed-off-by: Cornelia Huck <address@hidden>
(cherry picked from commit 882b3b97697affb36ca3d174f42f846232008979)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 529d45e151d82a772cd9b9af64bb25f88fba6567
      
https://github.com/qemu/qemu/commit/529d45e151d82a772cd9b9af64bb25f88fba6567
  Author: Michael Roth <address@hidden>
  Date:   2016-09-29 (Thu, 29 Sep 2016)

  Changed paths:
    M VERSION

  Log Message:
  -----------
  Update version for 2.6.2 release

Signed-off-by: Michael Roth <address@hidden>


Compare: https://github.com/qemu/qemu/compare/fcf75ad007b7...529d45e151d8

reply via email to

[Prev in Thread] Current Thread [Next in Thread]