vfio/type1: Limit DMA mappings per container
authorAlex Williamson <alex.williamson@redhat.com>
Wed, 3 Apr 2019 18:36:21 +0000 (12:36 -0600)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 4 May 2019 06:49:10 +0000 (08:49 +0200)
commit4f97abd571ec3d56c50a2edfe0932059f4549afa
tree5a0eaff4ce88e3161cfa99a742d30224280fe6de
parentb491c6f370eaac686161a0cb5cefc93a875dafed
vfio/type1: Limit DMA mappings per container

commit 492855939bdb59c6f947b0b5b44af9ad82b7e38c upstream.

Memory backed DMA mappings are accounted against a user's locked
memory limit, including multiple mappings of the same memory.  This
accounting bounds the number of such mappings that a user can create.
However, DMA mappings that are not backed by memory, such as DMA
mappings of device MMIO via mmaps, do not make use of page pinning
and therefore do not count against the user's locked memory limit.
These mappings still consume memory, but the memory is not well
associated to the process for the purpose of oom killing a task.

To add bounding on this use case, we introduce a limit to the total
number of concurrent DMA mappings that a user is allowed to create.
This limit is exposed as a tunable module option where the default
value of 64K is expected to be well in excess of any reasonable use
case (a large virtual machine configuration would typically only make
use of tens of concurrent mappings).

This fixes CVE-2019-3882.

Reviewed-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
[groeck: Adjust for missing upstream commit]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/vfio/vfio_iommu_type1.c