On Fri, Jul 23, 2021 at 09:58:43PM +0200, Philippe Mathieu-Daudé wrote:
> When the NVMe block driver was introduced (see commit bdd6a90a9e5,
> January 2018), Linux VFIO_IOMMU_MAP_DMA ioctl was only returning
> -ENOMEM in case of error. The driver was correctly handling the
> error path to recycle its volatile IOVA mappings.
>
> To fix CVE-2019-3882, Linux commit 492855939bdb ("vfio/type1: Limit
> DMA mappings per container", April 2019) added the -ENOSPC error to
> signal the user exhausted the DMA mappings available for a container.
>
> The block driver started to mis-behave:
>
> qemu-system-x86_64: VFIO_MAP_DMA failed: No space left on device
> (qemu)
> (qemu) info status
> VM status: paused (io-error)
> (qemu) c
> VFIO_MAP_DMA failed: No space left on device
> (qemu) c
> VFIO_MAP_DMA failed: No space left on device
>
> (The VM is not resumable from here, hence stuck.)
>
> Fix by handling the new -ENOSPC error (when DMA mappings are
> exhausted) without any distinction to the current -ENOMEM error,
> so we don't change the behavior on old kernels where the CVE-2019-3882
> fix is not present.
>
> An easy way to reproduce this bug is to restrict the DMA mapping
> limit (65535 by default) when loading the VFIO IOMMU module:
>
> # modprobe vfio_iommu_type1 dma_entry_limit=666
>
> Cc: qemu-sta...@nongnu.org
> Cc: Fam Zheng <f...@euphon.net>
> Cc: Maxim Levitsky <mlevi...@redhat.com>
> Cc: Alex Williamson <alex.william...@redhat.com>
> Reported-by: Michal Prívozník <mpriv...@redhat.com>
> Fixes: bdd6a90a9e5 ("block: Add VFIO based NVMe driver")
> Buglink: https://bugs.launchpad.net/qemu/+bug/1863333
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/65
> Signed-off-by: Philippe Mathieu-Daudé <phi...@redhat.com>
> ---
> v3: Reworded (Fam)
> v2: KISS checking both errors undistinguishedly (Maxim)
> ---
> block/nvme.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)Thanks, applied to my block tree: https://gitlab.com/stefanha/qemu/commits/block Stefan
signature.asc
Description: PGP signature
