[dpdk-dev] [PATCH v1 1/1] vfio: fix partial unmap check

[dpdk-dev] [PATCH v1 1/1] vfio: fix partial unmap check

[Anatoly Burakov]

Partial unmap support was introduced in commit c13ca4e81cac, and with it
was added a check that dereferenced the IOMMU type to determine whether
partial ummapping is supported for currently configured IOMMU type. In
certain circumstances (such as when VFIO is supported, but no devices
were bound to the VFIO driver), the IOMMU type pointer can be NULL.

However, dereferencing of IOMMU type was guarded by access to the user
maps list - that is, we were always checking the user map list first,
and then, if we found a memory region that encloses the one we're trying
to unmap, we would have performed the IOMMU type check.

This ensured that the IOMMU type check will not cause any NULL pointer
dereferences, because in order for an IOMMU type check to have been
performed, there necessarily must have been at least one memory region
that was previously mapped successfully, and that implies having a
defined IOMMU type.

When 56259f7fc010 was introduced, the IOMMU type check was moved to
before we were traversing the user mem maps list, thereby introducing a
potential NULL dereference, because the IOMMU type access was no longer
guarded by the user mem maps list traversal.

Fix the issue by moving the IOMMU type check to after the user mem maps
traversal, thereby ensuring that by the time the check happens, the
IOMMU type is always valid.

Fixes: 56259f7fc010 ("vfio: allow partially unmapping adjacent memory")
Cc: xuan.ding@intel.com

Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
 lib/eal/linux/eal_vfio.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/eal/linux/eal_vfio.c b/lib/eal/linux/eal_vfio.c
index 657c89ca58..aa2087a2da 100644
--- a/lib/eal/linux/eal_vfio.c
+++ b/lib/eal/linux/eal_vfio.c
@@ -1943,9 +1943,6 @@ container_dma_unmap(struct vfio_config *vfio_cfg, uint64_t vaddr, uint64_t iova,
 	 * mappings, let's just rebuild them using information we have.
 	 */
 
-	/* do we have partial unmap capability? */
-	has_partial_unmap = vfio_cfg->vfio_iommu_type->partial_unmap;
-
 	/*
 	 * first thing to do is check if there exists a mapping that includes
 	 * the start and the end of our requested unmap. We need to collect all
@@ -1961,6 +1958,9 @@ container_dma_unmap(struct vfio_config *vfio_cfg, uint64_t vaddr, uint64_t iova,
 		goto out;
 	}
 
+	/* do we have partial unmap capability? */
+	has_partial_unmap = vfio_cfg->vfio_iommu_type->partial_unmap;
+
 	/*
 	 * if we don't support partial unmap, we must check if start and end of
 	 * current unmap region are chunk-aligned.
-- 
2.25.1

Re: [dpdk-dev] [PATCH v1 1/1] vfio: fix partial unmap check

[David Marchand]

On Tue, Oct 26, 2021 at 3:30 PM Anatoly Burakov
<anatoly.burakov@intel.com> wrote:
>
> Partial unmap support was introduced in commit c13ca4e81cac, and with it
> was added a check that dereferenced the IOMMU type to determine whether
> partial ummapping is supported for currently configured IOMMU type. In
> certain circumstances (such as when VFIO is supported, but no devices
> were bound to the VFIO driver), the IOMMU type pointer can be NULL.
>
> However, dereferencing of IOMMU type was guarded by access to the user
> maps list - that is, we were always checking the user map list first,
> and then, if we found a memory region that encloses the one we're trying
> to unmap, we would have performed the IOMMU type check.
>
> This ensured that the IOMMU type check will not cause any NULL pointer
> dereferences, because in order for an IOMMU type check to have been
> performed, there necessarily must have been at least one memory region
> that was previously mapped successfully, and that implies having a
> defined IOMMU type.
>
> When 56259f7fc010 was introduced, the IOMMU type check was moved to
> before we were traversing the user mem maps list, thereby introducing a
> potential NULL dereference, because the IOMMU type access was no longer
> guarded by the user mem maps list traversal.
>
> Fix the issue by moving the IOMMU type check to after the user mem maps
> traversal, thereby ensuring that by the time the check happens, the
> IOMMU type is always valid.
>
> Fixes: 56259f7fc010 ("vfio: allow partially unmapping adjacent memory")
> Cc: xuan.ding@intel.com
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>

I guess Xuan tested it too, since we have a vhost patch on top of this
vfio patch.
Can you just confirm it is ok to merge?

Thanks.


-- 
David Marchand

Re: [dpdk-dev] [PATCH v1 1/1] vfio: fix partial unmap check

[Ding, Xuan]

Hi David,

>-----Original Message-----
>From: David Marchand <david.marchand@redhat.com>
>Sent: Wednesday, October 27, 2021 10:49 PM
>To: Burakov, Anatoly <anatoly.burakov@intel.com>; Ding, Xuan
><xuan.ding@intel.com>
>Cc: dev <dev@dpdk.org>; Maxime Coquelin <maxime.coquelin@redhat.com>
>Subject: Re: [dpdk-dev] [PATCH v1 1/1] vfio: fix partial unmap check
>
>On Tue, Oct 26, 2021 at 3:30 PM Anatoly Burakov
><anatoly.burakov@intel.com> wrote:
>>
>> Partial unmap support was introduced in commit c13ca4e81cac, and with it
>> was added a check that dereferenced the IOMMU type to determine
>whether
>> partial ummapping is supported for currently configured IOMMU type. In
>> certain circumstances (such as when VFIO is supported, but no devices
>> were bound to the VFIO driver), the IOMMU type pointer can be NULL.
>>
>> However, dereferencing of IOMMU type was guarded by access to the user
>> maps list - that is, we were always checking the user map list first,
>> and then, if we found a memory region that encloses the one we're trying
>> to unmap, we would have performed the IOMMU type check.
>>
>> This ensured that the IOMMU type check will not cause any NULL pointer
>> dereferences, because in order for an IOMMU type check to have been
>> performed, there necessarily must have been at least one memory region
>> that was previously mapped successfully, and that implies having a
>> defined IOMMU type.
>>
>> When 56259f7fc010 was introduced, the IOMMU type check was moved to
>> before we were traversing the user mem maps list, thereby introducing a
>> potential NULL dereference, because the IOMMU type access was no longer
>> guarded by the user mem maps list traversal.
>>
>> Fix the issue by moving the IOMMU type check to after the user mem maps
>> traversal, thereby ensuring that by the time the check happens, the
>> IOMMU type is always valid.
>>
>> Fixes: 56259f7fc010 ("vfio: allow partially unmapping adjacent memory")
>> Cc: xuan.ding@intel.com
>>
>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
>Reviewed-by: David Marchand <david.marchand@redhat.com>
>
>I guess Xuan tested it too, since we have a vhost patch on top of this
>vfio patch.
>Can you just confirm it is ok to merge?

Yes, I tested it and it works fine.

Tested-by: Xuan Ding <xuan.ding@intel.com>

Regards,
Xuan


>
>Thanks.
>
>
>--
>David Marchand

Re: [dpdk-dev] [PATCH v1 1/1] vfio: fix partial unmap check

[David Marchand]

On Thu, Oct 28, 2021 at 8:06 AM Ding, Xuan <xuan.ding@intel.com> wrote:
> >> Partial unmap support was introduced in commit c13ca4e81cac, and with it
> >> was added a check that dereferenced the IOMMU type to determine
> >whether
> >> partial ummapping is supported for currently configured IOMMU type. In
> >> certain circumstances (such as when VFIO is supported, but no devices
> >> were bound to the VFIO driver), the IOMMU type pointer can be NULL.
> >>
> >> However, dereferencing of IOMMU type was guarded by access to the user
> >> maps list - that is, we were always checking the user map list first,
> >> and then, if we found a memory region that encloses the one we're trying
> >> to unmap, we would have performed the IOMMU type check.
> >>
> >> This ensured that the IOMMU type check will not cause any NULL pointer
> >> dereferences, because in order for an IOMMU type check to have been
> >> performed, there necessarily must have been at least one memory region
> >> that was previously mapped successfully, and that implies having a
> >> defined IOMMU type.
> >>
> >> When 56259f7fc010 was introduced, the IOMMU type check was moved to
> >> before we were traversing the user mem maps list, thereby introducing a
> >> potential NULL dereference, because the IOMMU type access was no longer
> >> guarded by the user mem maps list traversal.
> >>
> >> Fix the issue by moving the IOMMU type check to after the user mem maps
> >> traversal, thereby ensuring that by the time the check happens, the
> >> IOMMU type is always valid.
> >>
> >> Fixes: 56259f7fc010 ("vfio: allow partially unmapping adjacent memory")
> >> Cc: xuan.ding@intel.com
> >>
> >> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> >Reviewed-by: David Marchand <david.marchand@redhat.com>
> Tested-by: Xuan Ding <xuan.ding@intel.com>

Applied, thanks.


-- 
David Marchand