Re: [PATCH v3 1/4] drm/panthor: Add vm_bind region with kbo range overlap check

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Page table bulk allocations for VM bindings are not accounted to the requesting process's memcg, allowing an unprivileged user to easily exhaust system memory and trigger an Out-Of-Memory (OOM) panic via huge sparse mappings.
--

commit 4e78b0100b6b8317cc7157628ece362a9c968f70
Author: Adrián Larumbe <adrian.larumbe@collabora.com>

drm/panthor: Add vm_bind region with kbo range overlap check

When a VM is created, caller has to specify the range of the address space
carve-out set aside for mapping kernel BO's. This patch ensures that vm_bind
mappings of UM-exposed BO's do not intersect with that region. It stores the
end of the user VA range at VM creation time and performs a quick check in
the vm_bind ioctl path.

> diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/panthor/panthor_mmu.c
> index 31cc57029c12c..94789777aac48 100644
> --- a/drivers/gpu/drm/panthor/panthor_mmu.c
> +++ b/drivers/gpu/drm/panthor/panthor_mmu.c

[ ... ]

> @@ -2981,6 +2986,10 @@ panthor_vm_bind_prepare_op_ctx(struct drm_file *file,
>  	if (!IS_ALIGNED(op->va | op->size | op->bo_offset, vm_pgsz))
>  		return -EINVAL;
>  
> +	/* We don't allow mappings that overlap with kbo's reserved range */
> +	if (op->va + op->size > vm->user_va_range)
> +		return -EINVAL;
> +
>  	switch (op->flags & DRM_PANTHOR_VM_BIND_OP_TYPE_MASK) {
>  	case DRM_PANTHOR_VM_BIND_OP_TYPE_MAP:
>  		if (!(op->flags & DRM_PANTHOR_VM_BIND_OP_MAP_SPARSE)) {

[Severity: High]
This is a pre-existing issue, but I noticed a potential memory exhaustion issue
with sparse mappings here.

When an unprivileged user submits a DRM_IOCTL_PANTHOR_VM_BIND ioctl with the
DRM_PANTHOR_VM_BIND_OP_MAP_SPARSE flag and an extremely large op->size (e.g.,
1TB), it appears it can exhaust system memory.

In panthor_vm_op_ctx_prealloc_pts(), a massive pt_count is derived from this
size and allocations are made using GFP_KERNEL:

panthor_mmu.c:panthor_vm_op_ctx_prealloc_pts() {
    ...
	op_ctx->rsvd_page_tables.pages = kzalloc_objs(*op_ctx->rsvd_page_tables.pages,
						      pt_count);
	if (!op_ctx->rsvd_page_tables.pages)
		return -ENOMEM;

	ret = kmem_cache_alloc_bulk(pt_cache, GFP_KERNEL, pt_count,
				    op_ctx->rsvd_page_tables.pages);
    ...
}

Since pt_cache was created in panthor_mmu_pt_cache_init() without the
SLAB_ACCOUNT flag:

panthor_mmu.c:panthor_mmu_pt_cache_init() {
    ...
	pt_cache = kmem_cache_create("panthor-mmu-pt", SZ_4K, SZ_4K, 0, NULL);
    ...
}

Should pt_cache be created with SLAB_ACCOUNT to ensure these massive allocations
are charged to the requesting process's memory control group (memcg) and prevent
Out-Of-Memory panics?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629-vm_bind_checks-v3-0-85e6740f6c2e@collabora.com?part=1