[Bug 217168] New: mmap length not validated in drm_gem_dma_mmap()

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=217168

            Bug ID: 217168
           Summary: mmap length not validated in drm_gem_dma_mmap()
           Product: Drivers
           Version: 2.5
    Kernel Version: 6.2
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Video(DRI - non Intel)
          Assignee: drivers_video-dri@kernel-bugs.osdl.org
          Reporter: mk@maintech.de
        Regression: No

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.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.