qemu-commits
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] abe300: virtio-net: fix map leaking on error

From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] abe300: virtio-net: fix map leaking on error during receive
Date: Tue, 15 Mar 2022 02:58:44 -0700 
  Branch: refs/heads/staging
  Home:   https://github.com/qemu/qemu
  Commit: abe300d9d894f7138e1af7c8e9c88c04bfe98b37
      
https://github.com/qemu/qemu/commit/abe300d9d894f7138e1af7c8e9c88c04bfe98b37
  Author: Jason Wang <jasowang@redhat.com>
  Date:   2022-03-15 (Tue, 15 Mar 2022)

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

  Log Message:
  -----------
  virtio-net: fix map leaking on error during receive

Commit bedd7e93d0196 ("virtio-net: fix use after unmap/free for sg")
tries to fix the use after free of the sg by caching the virtqueue
elements in an array and unmap them at once after receiving the
packets, But it forgot to unmap the cached elements on error which
will lead to leaking of mapping and other unexpected results.

Fixing this by detaching the cached elements on error. This addresses
CVE-2022-26353.

Reported-by: Victor Tom <vv474172261@gmail.com>
Cc: qemu-stable@nongnu.org
Fixes: CVE-2022-26353
Fixes: bedd7e93d0196 ("virtio-net: fix use after unmap/free for sg")
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: 10857ec0ad5d201d524d20b477da1cf3f7f4a3b0
      
https://github.com/qemu/qemu/commit/10857ec0ad5d201d524d20b477da1cf3f7f4a3b0
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-15 (Tue, 15 Mar 2022)

  Changed paths:
    M hw/virtio/meson.build
    A hw/virtio/vhost-shadow-virtqueue.c
    A hw/virtio/vhost-shadow-virtqueue.h

  Log Message:
  -----------
  vhost: Add VhostShadowVirtqueue

Vhost shadow virtqueue (SVQ) is an intermediate jump for virtqueue
notifications and buffers, allowing qemu to track them. While qemu is
forwarding the buffers and virtqueue changes, it is able to commit the
memory it's being dirtied, the same way regular qemu's VirtIO devices
do.

This commit only exposes basic SVQ allocation and free. Next patches of
the series add functionality like notifications and buffers forwarding.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: dff4426fa6562b6837ddc662a61836ae11ac4fae
      
https://github.com/qemu/qemu/commit/dff4426fa6562b6837ddc662a61836ae11ac4fae
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-15 (Tue, 15 Mar 2022)

  Changed paths:
    M hw/virtio/vhost-shadow-virtqueue.c
    M hw/virtio/vhost-shadow-virtqueue.h
    M hw/virtio/vhost-vdpa.c
    M include/hw/virtio/vhost-vdpa.h

  Log Message:
  -----------
  vhost: Add Shadow VirtQueue kick forwarding capabilities

At this mode no buffer forwarding will be performed in SVQ mode: Qemu
will just forward the guest's kicks to the device.

Host memory notifiers regions are left out for simplicity, and they will
not be addressed in this series.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: a8ac88585da1a3ae9c48bfd9e04430e895dc912d
      
https://github.com/qemu/qemu/commit/a8ac88585da1a3ae9c48bfd9e04430e895dc912d
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-15 (Tue, 15 Mar 2022)

  Changed paths:
    M hw/virtio/vhost-shadow-virtqueue.c
    M hw/virtio/vhost-shadow-virtqueue.h
    M hw/virtio/vhost-vdpa.c

  Log Message:
  -----------
  vhost: Add Shadow VirtQueue call forwarding capabilities

This will make qemu aware of the device used buffers, allowing it to
write the guest memory with its contents if needed.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: 4725a4181b0fd5b646c51f079d7eac753b14b094
      
https://github.com/qemu/qemu/commit/4725a4181b0fd5b646c51f079d7eac753b14b094
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-15 (Tue, 15 Mar 2022)

  Changed paths:
    M hw/virtio/vhost-shadow-virtqueue.c
    M hw/virtio/vhost-shadow-virtqueue.h
    M hw/virtio/vhost-vdpa.c

  Log Message:
  -----------
  vhost: Add vhost_svq_valid_features to shadow vq

This allows SVQ to negotiate features with the guest and the device. For
the device, SVQ is a driver. While this function bypasses all
non-transport features, it needs to disable the features that SVQ does
not support when forwarding buffers. This includes packed vq layout,
indirect descriptors or event idx.

Future changes can add support to offer more features to the guest,
since the use of VirtQueue gives this for free. This is left out at the
moment for simplicity.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: dafb34c9926a38b3bfc4ab8f35a99ca1c706648c
      
https://github.com/qemu/qemu/commit/dafb34c9926a38b3bfc4ab8f35a99ca1c706648c
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-15 (Tue, 15 Mar 2022)

  Changed paths:
    M hw/virtio/vhost-shadow-virtqueue.c
    M hw/virtio/vhost-shadow-virtqueue.h

  Log Message:
  -----------
  virtio: Add vhost_svq_get_vring_addr

It reports the shadow virtqueue address from qemu virtual address space.

Since this will be different from the guest's vaddr, but the device can
access it, SVQ takes special care about its alignment & lack of garbage
data. It assumes that IOMMU will work in host_page_size ranges for that.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: d96be4c8942a9f983f8a1642b397150d0d80c6ea
      
https://github.com/qemu/qemu/commit/d96be4c8942a9f983f8a1642b397150d0d80c6ea
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-15 (Tue, 15 Mar 2022)

  Changed paths:
    M hw/virtio/vhost-vdpa.c

  Log Message:
  -----------
  vdpa: adapt vhost_ops callbacks to svq

First half of the buffers forwarding part, preparing vhost-vdpa
callbacks to SVQ to offer it. QEMU cannot enable it at this moment, so
this is effectively dead code at the moment, but it helps to reduce
patch size.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: 100890f7cad502b6fa49465ffff287ba79fcf94b
      
https://github.com/qemu/qemu/commit/100890f7cad502b6fa49465ffff287ba79fcf94b
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-15 (Tue, 15 Mar 2022)

  Changed paths:
    M hw/virtio/vhost-shadow-virtqueue.c
    M hw/virtio/vhost-shadow-virtqueue.h
    M hw/virtio/vhost-vdpa.c

  Log Message:
  -----------
  vhost: Shadow virtqueue buffers forwarding

Initial version of shadow virtqueue that actually forward buffers. There
is no iommu support at the moment, and that will be addressed in future
patches of this series. Since all vhost-vdpa devices use forced IOMMU,
this means that SVQ is not usable at this point of the series on any
device.

For simplicity it only supports modern devices, that expects vring
in little endian, with split ring and no event idx or indirect
descriptors. Support for them will not be added in this series.

It reuses the VirtQueue code for the device part. The driver part is
based on Linux's virtio_ring driver, but with stripped functionality
and optimizations so it's easier to review.

However, forwarding buffers have some particular pieces: One of the most
unexpected ones is that a guest's buffer can expand through more than
one descriptor in SVQ. While this is handled gracefully by qemu's
emulated virtio devices, it may cause unexpected SVQ queue full. This
patch also solves it by checking for this condition at both guest's
kicks and device's calls. The code may be more elegant in the future if
SVQ code runs in its own iocontext.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: 9376bde894e444ebe2d2ec236569b6e55faa4765
      
https://github.com/qemu/qemu/commit/9376bde894e444ebe2d2ec236569b6e55faa4765
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-15 (Tue, 15 Mar 2022)

  Changed paths:
    M include/qemu/iova-tree.h
    M util/iova-tree.c

  Log Message:
  -----------
  util: Add iova_tree_alloc_map

This iova tree function allows it to look for a hole in allocated
regions and return a totally new translation for a given translated
address.

It's usage is mainly to allow devices to access qemu address space,
remapping guest's one into a new iova space where qemu can add chunks of
addresses.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: 193d17be0b84cce87db4426622cd4e6b827cae2a
      
https://github.com/qemu/qemu/commit/193d17be0b84cce87db4426622cd4e6b827cae2a
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-15 (Tue, 15 Mar 2022)

  Changed paths:
    M include/qemu/iova-tree.h
    M util/iova-tree.c

  Log Message:
  -----------
  util: add iova_tree_find_iova

This function does the reverse operation of iova_tree_find: To look for
a mapping that match a translated address so we can do the reverse.

This have linear complexity instead of logarithmic, but it supports
overlapping HVA. Future developments could reduce it.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: ec6122d8828e0e1268ec520542f8a7622d84f571
      
https://github.com/qemu/qemu/commit/ec6122d8828e0e1268ec520542f8a7622d84f571
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-15 (Tue, 15 Mar 2022)

  Changed paths:
    M hw/virtio/meson.build
    A hw/virtio/vhost-iova-tree.c
    A hw/virtio/vhost-iova-tree.h

  Log Message:
  -----------
  vhost: Add VhostIOVATree

This tree is able to look for a translated address from an IOVA address.

At first glance it is similar to util/iova-tree. However, SVQ working on
devices with limited IOVA space need more capabilities, like allocating
IOVA chunks or performing reverse translations (qemu addresses to iova).

The allocation capability, as "assign a free IOVA address to this chunk
of memory in qemu's address space" allows shadow virtqueue to create a
new address space that is not restricted by guest's addressable one, so
we can allocate shadow vqs vrings outside of it.

It duplicates the tree so it can search efficiently in both directions,
and it will signal overlap if iova or the translated address is present
in any tree.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: 34e3c94edaef2e0748ebb7bc6bb83a970345a6ad
      
https://github.com/qemu/qemu/commit/34e3c94edaef2e0748ebb7bc6bb83a970345a6ad
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-15 (Tue, 15 Mar 2022)

  Changed paths:
    M hw/virtio/vhost-shadow-virtqueue.c
    M hw/virtio/vhost-shadow-virtqueue.h
    M hw/virtio/vhost-vdpa.c
    M include/hw/virtio/vhost-vdpa.h

  Log Message:
  -----------
  vdpa: Add custom IOTLB translations to SVQ

Use translations added in VhostIOVATree in SVQ.

Only introduce usage here, not allocation and deallocation. As with
previous patches, we use the dead code paths of shadow_vqs_enabled to
avoid commiting too many changes at once. These are impossible to take
at the moment.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: 6d0b222666339d09910d495c65e6abb7d404fc2b
      
https://github.com/qemu/qemu/commit/6d0b222666339d09910d495c65e6abb7d404fc2b
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-15 (Tue, 15 Mar 2022)

  Changed paths:
    M hw/virtio/vhost-vdpa.c

  Log Message:
  -----------
  vdpa: Adapt vhost_vdpa_get_vring_base to SVQ

This is needed to achieve migration, so the destination can restore its
index.

Setting base as last used idx, so destination will see as available all
the entries that the device did not use, including the in-flight
processing ones.

This is ok for networking, but other kinds of devices might have
problems with these retransmissions.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: 773ebc952ee028e6c0dbeee15f1c36ab28325899
      
https://github.com/qemu/qemu/commit/773ebc952ee028e6c0dbeee15f1c36ab28325899
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-15 (Tue, 15 Mar 2022)

  Changed paths:
    M hw/virtio/vhost-vdpa.c

  Log Message:
  -----------
  vdpa: Never set log_base addr if SVQ is enabled

Setting the log address would make the device start reporting invalid
dirty memory because the SVQ vrings are located in qemu's memory.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: 12a195fa343aae2ead1301ce04727bd0ae25eb15
      
https://github.com/qemu/qemu/commit/12a195fa343aae2ead1301ce04727bd0ae25eb15
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-15 (Tue, 15 Mar 2022)

  Changed paths:
    M hw/virtio/vhost-vdpa.c
    M include/hw/virtio/vhost-vdpa.h

  Log Message:
  -----------
  vdpa: Expose VHOST_F_LOG_ALL on SVQ

SVQ is able to log the dirty bits by itself, so let's use it to not
block migration.

Also, ignore set and clear of VHOST_F_LOG_ALL on set_features if SVQ is
enabled. Even if the device supports it, the reports would be nonsense
because SVQ memory is in the qemu region.

The log region is still allocated. Future changes might skip that, but
this series is already long enough.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: a72ada1662ee3105c5d66ddc8930d98e9cab62be
      
https://github.com/qemu/qemu/commit/a72ada1662ee3105c5d66ddc8930d98e9cab62be
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2022-03-15 (Tue, 15 Mar 2022)

  Changed paths:
    M hw/net/virtio-net.c
    M hw/virtio/meson.build
    A hw/virtio/vhost-iova-tree.c
    A hw/virtio/vhost-iova-tree.h
    A hw/virtio/vhost-shadow-virtqueue.c
    A hw/virtio/vhost-shadow-virtqueue.h
    M hw/virtio/vhost-vdpa.c
    M include/hw/virtio/vhost-vdpa.h
    M include/qemu/iova-tree.h
    M util/iova-tree.c

  Log Message:
  -----------
  Merge tag 'net-pull-request' of https://github.com/jasowang/qemu into staging

# gpg: Signature made Tue 15 Mar 2022 05:58:55 GMT
# gpg:                using RSA key EF04965B398D6211
# gpg: Good signature from "Jason Wang (Jason Wang on RedHat) 
<jasowang@redhat.com>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg:          It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 215D 46F4 8246 689E C77F  3562 EF04 965B 398D 6211

* tag 'net-pull-request' of https://github.com/jasowang/qemu:
  vdpa: Expose VHOST_F_LOG_ALL on SVQ
  vdpa: Never set log_base addr if SVQ is enabled
  vdpa: Adapt vhost_vdpa_get_vring_base to SVQ
  vdpa: Add custom IOTLB translations to SVQ
  vhost: Add VhostIOVATree
  util: add iova_tree_find_iova
  util: Add iova_tree_alloc_map
  vhost: Shadow virtqueue buffers forwarding
  vdpa: adapt vhost_ops callbacks to svq
  virtio: Add vhost_svq_get_vring_addr
  vhost: Add vhost_svq_valid_features to shadow vq
  vhost: Add Shadow VirtQueue call forwarding capabilities
  vhost: Add Shadow VirtQueue kick forwarding capabilities
  vhost: Add VhostShadowVirtqueue
  virtio-net: fix map leaking on error during receive

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


Compare: https://github.com/qemu/qemu/compare/6f4fe14b46f0...a72ada1662ee
reply via email to
[Prev in Thread] Current Thread [Next in Thread]