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 <[email protected]> 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/[email protected]?part=1
