[PATCH v2 0/2] drm/gpuvm: reject zero-length VM_BIND ranges at the shared gate

[PATCH v2 0/2] drm/gpuvm: reject zero-length VM_BIND ranges at the shared gate

[Zhenhao Wan]

v1 fixed this in the nouveau driver by rejecting a zero-length range in
nouveau_uvmm_validate_range(). Danilo pointed out that this should be
fixed in GPUVM instead, and he is right: the defect is in the core, so
this v2 moves the fix there.

A zero-length range passes drm_gpuvm_range_valid() (0 is page-aligned and
addr + 0 does not overflow), and the GPUVA interval tree then computes a
node's last key as addr + range - 1, which underflows to addr - 1. The
resulting inverted interval corrupts the augmented rb-tree. Because both
the underflowing arithmetic and the single validation gate live in
drm_gpuvm.c, the core protects no one: nouveau and msm are affected, while
xe and imagination are saved only by their own explicit checks near the
ioctl boundary. Patch 2 adds the rejection to drm_gpuvm_range_valid(),
closing the hole for all callers at once.

Fixing only the core would, however, interact badly with panthor. Its
synchronous VM_BIND path already treats a zero-length op as a no-op
(returns 0), but its asynchronous path does not: a zero-length async
MAP/UNMAP reaches drm_gpuvm_sm_map()/drm_gpuvm_sm_unmap(). Today a
zero-length async map into unmapped space can already insert a malformed
node there, so patch 1 fixes a pre-existing corruption on its own; and
once the core starts rejecting a zero range, panthor_vm_bind_run_job()
would additionally escalate the resulting -EINVAL to
panthor_vm_declare_unusable(), permanently killing the VM. Patch 1
therefore makes panthor's asynchronous path treat a zero-length op as a
no-op, matching its synchronous path, and must be applied before patch 2.

Both patches are Cc: stable.

Changes since v1:
- Move the fix from the nouveau driver into the GPUVM core
  (drm_gpuvm_range_valid()), per Danilo's feedback.
- Add a preparatory panthor patch so the core change does not regress
  panthor's asynchronous VM_BIND path.
- Link to v1: https://lore.kernel.org/all/20260812-nouveau-uvmm-pt-fixes-v1-1-ab3a823f946e@gmail.com

Signed-off-by: Zhenhao Wan <whi4ed0g@gmail.com>
---
Zhenhao Wan (2):
      drm/panthor: Treat a zero-length VM_BIND op as a no-op
      drm/gpuvm: reject zero-length range in drm_gpuvm_range_valid()

 drivers/gpu/drm/drm_gpuvm.c           | 6 ++++--
 drivers/gpu/drm/panthor/panthor_mmu.c | 9 +++++++++
 2 files changed, 13 insertions(+), 2 deletions(-)
---
base-commit: db2ddb87143519e20a95aa36c60b36107b736a58
change-id: 20260902-drm-gpuvm-zerorange-v2-a2148df386b8

Best regards,
--  
Zhenhao Wan <whi4ed0g@gmail.com>

[PATCH v2 1/2] drm/panthor: Treat a zero-length VM_BIND op as a no-op

[Zhenhao Wan]

panthor_vm_bind_exec_sync_op() short-circuits a zero-length operation: it
returns 0 immediately when op->size is 0. The asynchronous VM_BIND path
has no equivalent guard.

An async MAP or UNMAP with size == 0 is not rejected: only alignment is
checked in panthor_vm_bind_prepare_op_ctx() and IS_ALIGNED(0) is true, so
the op is queued and panthor_vm_exec_op() calls drm_gpuvm_sm_map() /
drm_gpuvm_sm_unmap() with a zero range. A zero-length map into unmapped
space then reaches drm_gpuva_insert(), where the GPUVA interval-tree last
key addr + range - 1 underflows to addr - 1 and a malformed node whose end
lies below its start can be inserted, corrupting the augmented interval
tree.

Mirror the synchronous path and treat a zero-length map or unmap as a no-op
in panthor_vm_exec_op(), before any lock is taken or the GPUVA tree is
touched. This also keeps the async path robust if the core drm_gpuvm range
validation is tightened to reject a zero range, which would otherwise make
panthor_vm_bind_run_job() flag the VM unusable on the resulting -EINVAL.

Fixes: 647810ec2476 ("drm/panthor: Add the MMU/VM logical block")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Cc: stable@vger.kernel.org
Signed-off-by: Zhenhao Wan <whi4ed0g@gmail.com>
---
 drivers/gpu/drm/panthor/panthor_mmu.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/panthor/panthor_mmu.c
index e592a8ebb478..93542f59cb5e 100644
--- a/drivers/gpu/drm/panthor/panthor_mmu.c
+++ b/drivers/gpu/drm/panthor/panthor_mmu.c
@@ -2591,6 +2591,15 @@ panthor_vm_exec_op(struct panthor_vm *vm, struct panthor_vm_op_ctx *op,
 	if (op_type == DRM_PANTHOR_VM_BIND_OP_TYPE_SYNC_ONLY)
 		return 0;
 
+	/*
+	 * A zero-length map or unmap is a no-op. The synchronous bind path
+	 * already short-circuits it in panthor_vm_bind_exec_sync_op(); mirror
+	 * that here so an asynchronous zero-length op does not fail and flag the
+	 * VM as unusable.
+	 */
+	if (!op->va.range)
+		return 0;
+
 	mutex_lock(&vm->op_lock);
 	vm->op_ctx = op;
 

-- 
2.34.1

Re: [PATCH v2 1/2] drm/panthor: Treat a zero-length VM_BIND op as a no-op

[Liviu Dudau]

On Wed, Sep 02, 2026 at 08:28:42PM +0800, Zhenhao Wan wrote:
> panthor_vm_bind_exec_sync_op() short-circuits a zero-length operation: it
> returns 0 immediately when op->size is 0. The asynchronous VM_BIND path
> has no equivalent guard.
> 
> An async MAP or UNMAP with size == 0 is not rejected: only alignment is
> checked in panthor_vm_bind_prepare_op_ctx() and IS_ALIGNED(0) is true, so
> the op is queued and panthor_vm_exec_op() calls drm_gpuvm_sm_map() /
> drm_gpuvm_sm_unmap() with a zero range. A zero-length map into unmapped
> space then reaches drm_gpuva_insert(), where the GPUVA interval-tree last
> key addr + range - 1 underflows to addr - 1 and a malformed node whose end
> lies below its start can be inserted, corrupting the augmented interval
> tree.
> 
> Mirror the synchronous path and treat a zero-length map or unmap as a no-op
> in panthor_vm_exec_op(), before any lock is taken or the GPUVA tree is
> touched. This also keeps the async path robust if the core drm_gpuvm range
> validation is tightened to reject a zero range, which would otherwise make
> panthor_vm_bind_run_job() flag the VM unusable on the resulting -EINVAL.
> 
> Fixes: 647810ec2476 ("drm/panthor: Add the MMU/VM logical block")
> Reported-by: Yuhao Jiang <danisjiang@gmail.com>
> Assisted-by: Claude:claude-opus-5
> Cc: stable@vger.kernel.org
> Signed-off-by: Zhenhao Wan <whi4ed0g@gmail.com>

Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>

Best regards,
Liviu

> ---
>  drivers/gpu/drm/panthor/panthor_mmu.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/panthor/panthor_mmu.c
> index e592a8ebb478..93542f59cb5e 100644
> --- a/drivers/gpu/drm/panthor/panthor_mmu.c
> +++ b/drivers/gpu/drm/panthor/panthor_mmu.c
> @@ -2591,6 +2591,15 @@ panthor_vm_exec_op(struct panthor_vm *vm, struct panthor_vm_op_ctx *op,
>  	if (op_type == DRM_PANTHOR_VM_BIND_OP_TYPE_SYNC_ONLY)
>  		return 0;
>  
> +	/*
> +	 * A zero-length map or unmap is a no-op. The synchronous bind path
> +	 * already short-circuits it in panthor_vm_bind_exec_sync_op(); mirror
> +	 * that here so an asynchronous zero-length op does not fail and flag the
> +	 * VM as unusable.
> +	 */
> +	if (!op->va.range)
> +		return 0;
> +
>  	mutex_lock(&vm->op_lock);
>  	vm->op_ctx = op;
>  
> 
> -- 
> 2.34.1
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH v2 2/2] drm/gpuvm: reject zero-length range in drm_gpuvm_range_valid()

[Zhenhao Wan]

drm_gpuvm_range_valid() is the common gate every GPUVM map/unmap path
funnels through: drm_gpuva_insert(), __drm_gpuvm_sm_map() and
__drm_gpuvm_sm_unmap() all reject a request unless it passes. It checks
for overflow, the managed-range bounds and kernel-node overlap, but it
never rejects a zero-length range. A range of 0 is page-aligned and
addr + 0 does not overflow, so a zero-length VM_BIND request from
userspace passes validation.

The GPUVA interval tree derives a node's last key as addr + range - 1
(GPUVA_LAST()). With range == 0 this underflows to addr - 1, producing
an interval whose end lies below its start (and, for addr == 0, wraps to
U64_MAX). __drm_gpuva_insert() then issues its overlap query with that
inverted interval, so the -EEXIST guard matches nothing and a malformed
zero-length node is inserted, corrupting the augmented interval tree's
subtree-last invariant and misleading the overlap checks of later
map/unmap operations on the same VM.

Because the shared helper's own kerneldoc promises to validate "the
range" yet silently accepts range == 0, drivers have papered over this
individually and inconsistently: imagination and xe reject a zero range
at/near the ioctl boundary, while nouveau and msm do not. Fix it once at
the common gate so every current and future caller is covered.

The only in-tree user that legitimately accepts a zero range,
xe's DRM_XE_VM_BIND_OP_UNMAP_ALL, interprets it at its ioctl layer and
never passes range == 0 into the GPUVM core, so it is unaffected. The
in-core lookups drm_gpuva_find_prev()/drm_gpuva_find_next() pass
range == 1 and are likewise unaffected.

Fixes: e6303f323b1a ("drm: manager to keep track of GPUs VA mappings")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Cc: stable@vger.kernel.org
Signed-off-by: Zhenhao Wan <whi4ed0g@gmail.com>
---
 drivers/gpu/drm/drm_gpuvm.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
index c422c5af1f4b..b73ad6988171 100644
--- a/drivers/gpu/drm/drm_gpuvm.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -1021,7 +1021,8 @@ drm_gpuvm_in_kernel_node(struct drm_gpuvm *gpuvm, u64 addr, u64 range)
  * @addr: the base address
  * @range: the range starting from the base address
  *
- * Checks whether the range is within the GPUVM's managed boundaries.
+ * Checks whether the range is non-zero and within the GPUVM's managed
+ * boundaries.
  *
  * Returns: true for a valid range, false otherwise
  */
@@ -1029,7 +1030,8 @@ bool
 drm_gpuvm_range_valid(struct drm_gpuvm *gpuvm,
 		      u64 addr, u64 range)
 {
-	return !drm_gpuvm_check_overflow(addr, range) &&
+	return range != 0 &&
+	       !drm_gpuvm_check_overflow(addr, range) &&
 	       drm_gpuvm_in_mm_range(gpuvm, addr, range) &&
 	       !drm_gpuvm_in_kernel_node(gpuvm, addr, range);
 }

-- 
2.34.1

Re: [PATCH v2 2/2] drm/gpuvm: reject zero-length range in drm_gpuvm_range_valid()

[Liviu Dudau]

On Wed, Sep 02, 2026 at 08:28:43PM +0800, Zhenhao Wan wrote:
> drm_gpuvm_range_valid() is the common gate every GPUVM map/unmap path
> funnels through: drm_gpuva_insert(), __drm_gpuvm_sm_map() and
> __drm_gpuvm_sm_unmap() all reject a request unless it passes. It checks
> for overflow, the managed-range bounds and kernel-node overlap, but it
> never rejects a zero-length range. A range of 0 is page-aligned and
> addr + 0 does not overflow, so a zero-length VM_BIND request from
> userspace passes validation.
> 
> The GPUVA interval tree derives a node's last key as addr + range - 1
> (GPUVA_LAST()). With range == 0 this underflows to addr - 1, producing
> an interval whose end lies below its start (and, for addr == 0, wraps to
> U64_MAX). __drm_gpuva_insert() then issues its overlap query with that
> inverted interval, so the -EEXIST guard matches nothing and a malformed
> zero-length node is inserted, corrupting the augmented interval tree's
> subtree-last invariant and misleading the overlap checks of later
> map/unmap operations on the same VM.
> 
> Because the shared helper's own kerneldoc promises to validate "the
> range" yet silently accepts range == 0, drivers have papered over this
> individually and inconsistently: imagination and xe reject a zero range
> at/near the ioctl boundary, while nouveau and msm do not. Fix it once at
> the common gate so every current and future caller is covered.
> 
> The only in-tree user that legitimately accepts a zero range,
> xe's DRM_XE_VM_BIND_OP_UNMAP_ALL, interprets it at its ioctl layer and
> never passes range == 0 into the GPUVM core, so it is unaffected. The
> in-core lookups drm_gpuva_find_prev()/drm_gpuva_find_next() pass
> range == 1 and are likewise unaffected.
> 
> Fixes: e6303f323b1a ("drm: manager to keep track of GPUs VA mappings")
> Reported-by: Yuhao Jiang <danisjiang@gmail.com>
> Assisted-by: Claude:claude-opus-5
> Cc: stable@vger.kernel.org
> Signed-off-by: Zhenhao Wan <whi4ed0g@gmail.com>

Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>

Best regards,
Liviu

> ---
>  drivers/gpu/drm/drm_gpuvm.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
> index c422c5af1f4b..b73ad6988171 100644
> --- a/drivers/gpu/drm/drm_gpuvm.c
> +++ b/drivers/gpu/drm/drm_gpuvm.c
> @@ -1021,7 +1021,8 @@ drm_gpuvm_in_kernel_node(struct drm_gpuvm *gpuvm, u64 addr, u64 range)
>   * @addr: the base address
>   * @range: the range starting from the base address
>   *
> - * Checks whether the range is within the GPUVM's managed boundaries.
> + * Checks whether the range is non-zero and within the GPUVM's managed
> + * boundaries.
>   *
>   * Returns: true for a valid range, false otherwise
>   */
> @@ -1029,7 +1030,8 @@ bool
>  drm_gpuvm_range_valid(struct drm_gpuvm *gpuvm,
>  		      u64 addr, u64 range)
>  {
> -	return !drm_gpuvm_check_overflow(addr, range) &&
> +	return range != 0 &&
> +	       !drm_gpuvm_check_overflow(addr, range) &&
>  	       drm_gpuvm_in_mm_range(gpuvm, addr, range) &&
>  	       !drm_gpuvm_in_kernel_node(gpuvm, addr, range);
>  }
> 
> -- 
> 2.34.1
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯