[PATCH] RDMA/rdmavt: Fix potential use-after-free in rvt_mmap()

[PATCH] RDMA/rdmavt: Fix potential use-after-free in rvt_mmap()

[Nguyen Van Tien]

rvt_mmap() drops the pending lock and only takes the VMA reference in
rvt_vma_open() after remap_vmalloc_range() returns. A concurrent owner
teardown can free ip->obj and ip between list_del_init() and the later
kref_get(), leaving rvt_mmap() operating on freed memory.

Apply the same fix pattern as the RXE provider (CVE-2026-64582): take
the reference with kref_get_unless_zero() while pending_lock is held,
release the lock only after the reference is secured, and on remap
failure clear the VMA state and put the reference.

Signed-off-by: Nguyen Van Tien <nguyenvantiennani@gmail.com>
---
 drivers/infiniband/sw/rdmavt/mmap.c | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/infiniband/sw/rdmavt/mmap.c b/drivers/infiniband/sw/rdmavt/mmap.c
index 473f464f3..318e8877b 100644
--- a/drivers/infiniband/sw/rdmavt/mmap.c
+++ b/drivers/infiniband/sw/rdmavt/mmap.c
@@ -100,15 +100,30 @@ int rvt_mmap(struct ib_ucontext *context, struct vm_area_struct *vma)
 		if (size > ip->size)
 			break;
 
+		/*
+		 * Increment refcount and check whether it is being freed atm
+		 * while holding the lock to prevent UAF, matching the RXE
+		 * provider fix.
+		 */
+		if (!kref_get_unless_zero(&ip->ref)) {
+			spin_unlock_irq(&rdi->pending_lock);
+			ret = -ENXIO;
+			goto done;
+		}
+
 		list_del_init(&ip->pending_mmaps);
 		spin_unlock_irq(&rdi->pending_lock);
 
-		ret = remap_vmalloc_range(vma, ip->obj, 0);
-		if (ret)
-			goto done;
 		vma->vm_ops = &rvt_vm_ops;
 		vma->vm_private_data = ip;
-		rvt_vma_open(vma);
+
+		ret = remap_vmalloc_range(vma, ip->obj, 0);
+		if (ret) {
+			vma->vm_private_data = NULL;
+			vma->vm_ops = NULL;
+			kref_put(&ip->ref, rvt_release_mmap_info);
+			goto done;
+		}
 		goto done;
 	}
 	spin_unlock_irq(&rdi->pending_lock);
-- 
2.53.0

Re: [PATCH] RDMA/rdmavt: Fix potential use-after-free in rvt_mmap()

[Dennis Dalessandro]

On 8/25/26 12:20 AM, Nguyen Van Tien wrote:
> rvt_mmap() drops the pending lock and only takes the VMA reference in
> rvt_vma_open() after remap_vmalloc_range() returns. A concurrent owner
> teardown can free ip->obj and ip between list_del_init() and the later
> kref_get(), leaving rvt_mmap() operating on freed memory.
> 
> Apply the same fix pattern as the RXE provider (CVE-2026-64582): take
> the reference with kref_get_unless_zero() while pending_lock is held,
> release the lock only after the reference is secured, and on remap
> failure clear the VMA state and put the reference.
> 
> Signed-off-by: Nguyen Van Tien <nguyenvantiennani@gmail.com>
> ---
>   drivers/infiniband/sw/rdmavt/mmap.c | 23 +++++++++++++++++++----
>   1 file changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/infiniband/sw/rdmavt/mmap.c b/drivers/infiniband/sw/rdmavt/mmap.c
> index 473f464f3..318e8877b 100644
> --- a/drivers/infiniband/sw/rdmavt/mmap.c
> +++ b/drivers/infiniband/sw/rdmavt/mmap.c
> @@ -100,15 +100,30 @@ int rvt_mmap(struct ib_ucontext *context, struct vm_area_struct *vma)
>   		if (size > ip->size)
>   			break;
>   
> +		/*
> +		 * Increment refcount and check whether it is being freed atm
> +		 * while holding the lock to prevent UAF, matching the RXE
> +		 * provider fix.
> +		 */
> +		if (!kref_get_unless_zero(&ip->ref)) {
> +			spin_unlock_irq(&rdi->pending_lock);
> +			ret = -ENXIO;
> +			goto done;
> +		}
> +
>   		list_del_init(&ip->pending_mmaps);
>   		spin_unlock_irq(&rdi->pending_lock);
>   
> -		ret = remap_vmalloc_range(vma, ip->obj, 0);
> -		if (ret)
> -			goto done;
>   		vma->vm_ops = &rvt_vm_ops;
>   		vma->vm_private_data = ip;
> -		rvt_vma_open(vma);
> +
> +		ret = remap_vmalloc_range(vma, ip->obj, 0);
> +		if (ret) {
> +			vma->vm_private_data = NULL;
> +			vma->vm_ops = NULL;
> +			kref_put(&ip->ref, rvt_release_mmap_info);
> +			goto done;
> +		}
>   		goto done;
>   	}
>   	spin_unlock_irq(&rdi->pending_lock);

My AI cranked out basically the same patch. Only it will be tested and 
reviewed. I'd say drop this and pick up my validated version. If you go 
with this one the commit message should be updated to explain why we 
aren't calling rvt_vma_open() anymore.

-Denny