In the drm_gem_dma_mmap() function (drm_gem_cma_mmap() for kernel versions before 6.1), the length of the requested mapping does not get validated against the length of the GEM buffer object. Therefore the user can gain full access to the physical memory after the GEM buffer by just mmap-ing the buffer with a larger length.


I *think* the correct way to fix this issue is to pass the actual size of the buffer as 'size' argument to the dma_mmap_wc/dma_mmap_pages function, instead of the user-requested length. (=> replace "vma->vm_end - vma->vm_start" by "dma_obj->base.size"). These functions then will validate the requested length against the buffer size and return -ENXIO if the length is too large. But I am in no means an expert in this area, so somebody with more experience should definitely confirm this. 


I have discovered this issue by using mmap on on an fbdev (/dev/fb0) created by the Xilinx 'ZynqMP DisplayPort Subsystem' DRM driver (/drivers/gpu/drm/xlnx/zynqmp_dpsub.c) and validated that I can actually use this to gain access to the physical memory behind the framebuffer. But as this is an generic helper function of the DRM GEM framework used by many different DRM drivers, I assume other DRM drivers are affected in a similar way.