[Qemu-commits] [qemu/qemu] d9bb78: virtio-net: fix map leaking on error during receive

[Peter Maydell]

  Branch: refs/heads/staging
  Home:   https://github.com/qemu/qemu
  Commit: d9bb7888d656ff758108ff50f664bdd03ef3b0f4
      
https://github.com/qemu/qemu/commit/d9bb7888d656ff758108ff50f664bdd03ef3b0f4
  Author: Jason Wang <jasowang@redhat.com>
  Date:   2022-03-10 (Thu, 10 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: 876315f8e263f3d0894dc081ebb02e8526782a71
      
https://github.com/qemu/qemu/commit/876315f8e263f3d0894dc081ebb02e8526782a71
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-10 (Thu, 10 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.

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


  Commit: 274139011543fc8c766d3f1559b6ec7b7103098c
      
https://github.com/qemu/qemu/commit/274139011543fc8c766d3f1559b6ec7b7103098c
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-10 (Thu, 10 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.

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


  Commit: d98529dc51d391a638934a520b3e3b2c353b1dc1
      
https://github.com/qemu/qemu/commit/d98529dc51d391a638934a520b3e3b2c353b1dc1
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-10 (Thu, 10 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.

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


  Commit: d41cf66a9284f6a94163bf5f542d1ef9d450d586
      
https://github.com/qemu/qemu/commit/d41cf66a9284f6a94163bf5f542d1ef9d450d586
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-10 (Thu, 10 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.

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


  Commit: 131977c403ea8dbfae830ccf255643641852d483
      
https://github.com/qemu/qemu/commit/131977c403ea8dbfae830ccf255643641852d483
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-10 (Thu, 10 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.

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


  Commit: 8d2cbfada2be274120a63cd88995a0e6082a23ed
      
https://github.com/qemu/qemu/commit/8d2cbfada2be274120a63cd88995a0e6082a23ed
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-10 (Thu, 10 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.

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


  Commit: 286261f47ec3874e1ba5ba7fd725d648972e2380
      
https://github.com/qemu/qemu/commit/286261f47ec3874e1ba5ba7fd725d648972e2380
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-10 (Thu, 10 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.

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


  Commit: d88e91d031b973880b297cf3fddd4da2eebd8c17
      
https://github.com/qemu/qemu/commit/d88e91d031b973880b297cf3fddd4da2eebd8c17
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-10 (Thu, 10 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.

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


  Commit: 7f72f00daa126a29da38be74fc4cc62dda2b6e89
      
https://github.com/qemu/qemu/commit/7f72f00daa126a29da38be74fc4cc62dda2b6e89
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-10 (Thu, 10 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.

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


  Commit: d915e432a9aa12d7275df6b95ecfb4d1a6be4923
      
https://github.com/qemu/qemu/commit/d915e432a9aa12d7275df6b95ecfb4d1a6be4923
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-10 (Thu, 10 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.

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


  Commit: 56f3a5ca3b5ce7863b2904aa8f53c2c4b4433d38
      
https://github.com/qemu/qemu/commit/56f3a5ca3b5ce7863b2904aa8f53c2c4b4433d38
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-10 (Thu, 10 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.

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


  Commit: ce1015ce4c40518375de09570988eaf7b6c698e9
      
https://github.com/qemu/qemu/commit/ce1015ce4c40518375de09570988eaf7b6c698e9
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-10 (Thu, 10 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.

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


  Commit: e171582c683aff1c9eb9f6ae14aa33287201082f
      
https://github.com/qemu/qemu/commit/e171582c683aff1c9eb9f6ae14aa33287201082f
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-10 (Thu, 10 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.

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


  Commit: eea40402ecf895ed345f8e8eb07dbb484f4542c5
      
https://github.com/qemu/qemu/commit/eea40402ecf895ed345f8e8eb07dbb484f4542c5
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-10 (Thu, 10 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.

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


  Commit: cd0bf23c4ac6b5e2b48d12736d204173154db868
      
https://github.com/qemu/qemu/commit/cd0bf23c4ac6b5e2b48d12736d204173154db868
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2022-03-10 (Thu, 10 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 remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into 
staging

# gpg: Signature made Thu 10 Mar 2022 02:28:06 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

* remotes/jasowang/tags/net-pull-request:
  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/1416688c53be...cd0bf23c4ac6