kernel/linux.git/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c, branch v4.14.286

drm/amdgpu: Fix buffer overflow in INFO ioctl

2020-09-03T09:22:32+00:00

commit b5b97cab55eb71daba3283c8b1d2cce456d511a1 upstream. The values for "se_num" and "sh_num" come from the user in the ioctl. They can be in the 0-255 range but if they're more than AMDGPU_GFX_MAX_SE (4) or AMDGPU_GFX_MAX_SH_PER_SE (2) then it results in an out of bounds read. Reported-by: Dan Carpenter Acked-by: Dan Carpenter Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: fix ref count leak in amdgpu_driver_open_kms

2020-09-03T09:22:25+00:00

[ Upstream commit 9ba8923cbbe11564dd1bf9f3602add9a9cfbb5c6 ] in amdgpu_driver_open_kms the call to pm_runtime_get_sync increments the counter even in case of failure, leading to incorrect ref count. In case of failure, decrement the ref count before returning. Signed-off-by: Navid Emamdoost Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()

2020-08-05T08:06:48+00:00

commit 543e8669ed9bfb30545fd52bc0e047ca4df7fb31 upstream. Compiler leaves a 4-byte hole near the end of `dev_info`, causing amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace when `size` is greater than 356. In 2015 we tried to fix this issue by doing `= {};` on `dev_info`, which unfortunately does not initialize that 4-byte hole. Fix it by using memset() instead. Cc: stable@vger.kernel.org Fixes: c193fa91b918 ("drm/amdgpu: information leak in amdgpu_info_ioctl()") Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") Suggested-by: Dan Carpenter Reviewed-by: Christian König Signed-off-by: Peilin Ye Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Bail earlier when amdgpu.cik_/si_support is not set to 1

2019-10-29T08:17:36+00:00

commit 984d7a929ad68b7be9990fc9c5cfa5d5c9fc7942 upstream. Bail from the pci_driver probe function instead of from the drm_driver load function. This avoid /dev/dri/card0 temporarily getting registered and then unregistered again, sending unwanted add / remove udev events to userspace. Specifically this avoids triggering the (userspace) bug fixed by this plymouth merge-request: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59 Note that despite that being a userspace bug, not sending unnecessary udev events is a good idea in general. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490 Reviewed-by: Daniel Vetter Signed-off-by: Hans de Goede Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Check for valid number of registers to read

2019-10-11T16:18:40+00:00

[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ] Do not try to allocate any amount of memory requested by the user. Instead limit it to 128 registers. Actually the longest series of consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and mmGB_MACROTILE_MODE0-15 (0x2644-0x2673). Bug: https://bugs.freedesktop.org/show_bug.cgi?id=111273 Signed-off-by: Trek Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/amdgpu: store fragment_size in vm_manager

2017-08-17T19:46:08+00:00

adds fragment_size in the vm_manager structure and implements hardware setup for it. Reviewed-by: Christian König Signed-off-by: Roger He Signed-off-by: Alex Deucher

drm/amdgpu: cleanup static CSA handling

2017-08-17T19:46:05+00:00

Move the CSA bo_va from the VM to the fpriv structure. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher

drm/amdgpu: move vram usage tracking into the vram manager v2

2017-08-17T19:46:03+00:00

Looks like a better place for this. v2: use atomic64_t members instead Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher

drm/amdgpu: move gtt usage tracking into the gtt manager v2

2017-08-17T19:46:02+00:00

It doesn't make much sense to count those numbers twice. v2: use and atomic64_t instead Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher

drm/amdgpu: Fix KFD initialization for multi-GPU systems

2017-08-15T18:46:02+00:00

kfd2kgd is device-specific, so it should not be a global variable. Merge amdgpu_amdkfd_load_interface and amdgpu_amdkfd_device_probe so that it's only needed as a local variable in one function. Signed-off-by: Felix Kuehling Reviewed-by: Oded Gabbay Signed-off-by: Alex Deucher