linux.git/drivers/gpu/drm/amd, branch v7.1-rc5

drm/amdgpu: fix handling in amdgpu_userq_create

2026-05-19T16:25:32+00:00

Well mostly the same issues the other code had as well:

1. Memory allocation while holding the userq_mutex lock is forbidden!
2. Things were created/started/published in the wrong order.
3. The reset lock was taken in the wrong order and seems to be
   unecessary in the first place.
4. Error messages on invalid input parameters can spam the logs.
5. Error messages on memory allocation failures are usually superflous
   as well.

Signed-off-by: Christian König 
Reviewed-by: Sunil Khatri 
Reviewed-by: Prike Liang 
Signed-off-by: Alex Deucher 
(cherry picked from commit 89e50de5654dbe7a137e03d78629542e17ba7202)

drm/amdgpu: userq_va_mapped should remain true once done

2026-05-19T16:15:49+00:00

Multiple queues needs these bo_va objects belonging to
the same uq_mgr. So once they are mapped lets not unmap
them as at any point of time any of the queues might be
using it.

Also userq_va_mapped should be a boolean than atomic.

Signed-off-by: Sunil Khatri 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
(cherry picked from commit 5c02889ea22575c3bcfdf212e65fac316cbc6c6a)

drm/amdgpu: avoid integer overflow in VA range check

2026-05-19T16:15:41+00:00

The original addition operation in 64-bit unsigned type may encounter
overflow situations. To prevent such issues and safely reject invalid
inputs, the check_add_overflow() function is used.

Signed-off-by: Ce Sun 
Reviewed-by: Tao Zhou 
Signed-off-by: Alex Deucher 
(cherry picked from commit cc768f4dd0bb9083c813683eeec44fc23921f771)

drm/amd/ras: Fix UMC error address allocation leak

2026-05-19T16:15:24+00:00

amdgpu_umc_handle_bad_pages() allocates err_data->err_addr before
querying UMC error information. In the direct and firmware query paths,
the pointer is reassigned to a fresh allocation before the original
buffer is released, so the initial allocation is leaked on each handled
event.

Free the existing buffer before replacing it in those query paths so the
function exit cleanup only owns the active allocation.

Signed-off-by: Xiang Liu 
Reviewed-by: Stanley.Yang 
Reviewed-by: Tao Zhou 
Signed-off-by: Alex Deucher 
(cherry picked from commit 911b1bdd22c3712a22b60fcc58f7b9f2d07b0803)

drm/amdgpu: unmap all user mappings of framebuffer and doorbell before mode1 reset

2026-05-19T16:14:55+00:00

During Mode 1 reset, the ASIC undergoes a reset cycle and becomes temporarily
inaccessible via PCIe. Any attempt to access framebuffer or MMIO registers during
this window can result in uncompleted PCIe transactions, leading to NMI panics or
system hangs.

To prevent this, Unmap all of the applications mappings of the framebuffer
and doorbell BARs before mode1 reset. Also prevent new mappings from coming in
during the reset process.

v2: remove inode in kfd_dev (Christian)
v3: correct unmap offset (Felix), remove prevent new mappings part
to avoid deadlock (Christian)

Reviewed-by: Felix Kuehling 
Signed-off-by: Yifan Zhang 
Signed-off-by: Alex Deucher 
(cherry picked from commit 70cadefcc6160c575b04f763ada34c20e868d577)

drm/amd/display: Validate payload length and link_index in dc_process_dmub_aux_transfer_async

2026-05-19T16:13:56+00:00

[Why&How]
dc_process_dmub_aux_transfer_async() copies payload->length bytes into a
16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which
is a no-op in release builds. If a caller ever passes length > 16 this
results in a stack buffer overflow via memcpy.

Additionally, link_index is used to dereference dc->links[] without
bounds checking against dc->link_count, risking an out-of-bounds access.

Replace the ASSERT with a hard runtime check that returns false when
payload->length exceeds the destination buffer size, and add a bounds
check for link_index before it is used.

Assisted-by: GitHub Copilot:Claude claude-4-opus
Reviewed-by: Alex Hung 
Signed-off-by: Harry Wentland 
Signed-off-by: Ivan Lipski 
Tested-by: Dan Wheeler 
Signed-off-by: Alex Deucher 
(cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881)
Cc: stable@vger.kernel.org

drm/amd/display: Validate GPIO pin LUT table size before iterating

2026-05-19T16:13:29+00:00

[Why&How]
The GPIO pin table parsers in get_gpio_i2c_info() and
bios_parser_get_gpio_pin_info() derive an element count from the VBIOS
table_header.structuresize field, then iterate over gpio_pin[] entries.
However, GET_IMAGE() only validates that the table header itself fits
within the BIOS image. If the VBIOS reports a structuresize larger than
the actual mapped data, the loop reads past the end of the BIOS image,
causing an out-of-bounds read.

Fix this by calling bios_get_image() to validate that the full claimed
structuresize is accessible within the BIOS image before entering the
loop in both functions.

Assisted-by: GitHub Copilot:claude-opus-4-6
Reviewed-by: Alex Hung 
Signed-off-by: Harry Wentland 
Signed-off-by: Ivan Lipski 
Tested-by: Dan Wheeler 
Signed-off-by: Alex Deucher 
(cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3)
Cc: stable@vger.kernel.org

drm/amd/display: Fix integer overflow in bios_get_image()

2026-05-19T16:13:07+00:00

[Why&How]
The bounds check in bios_get_image() computes 'offset + size' using
unsigned 32-bit arithmetic before comparing against bios_size. If a
VBIOS image contains a near-UINT32_MAX offset the addition wraps to a
small value, the comparison passes, and the function returns a wild
pointer past the VBIOS mapping.

Additionally, the comparison uses '<' (strict), which incorrectly
rejects the valid exact-fit case where offset + size == bios_size.

Fix both issues by restructuring the check to avoid the addition
entirely: first reject if offset alone exceeds bios_size, then check
size against the remaining space (bios_size - offset). This eliminates
the overflow and correctly permits exact-fit accesses.

Assisted-by: GitHub Copilot:claude-opus-4.6
Reviewed-by: Alex Hung 
Signed-off-by: Harry Wentland 
Signed-off-by: Ivan Lipski 
Tested-by: Dan Wheeler 
Signed-off-by: Alex Deucher 
(cherry picked from commit d40fb392af659c4a02b560319f226842f6ec1a95)
Cc: stable@vger.kernel.org

drm/amdkfd: Check bounds for allocate_sdma_queue restore_sdma_id

2026-05-19T16:11:43+00:00

allocate_sdma_queue has an option where the sdma queue id can be
specified (used by CRIU). We weren't bounds-checking that
value.

Confirm it's less than the maximum number of queues.

Signed-off-by: David Francis 
Reviewed-by: Harish Kasiviswanathan 
Signed-off-by: Alex Deucher 
(cherry picked from commit bfe9a7545b2a7be1c543f1741e16f2d5ec4116ae)

drm/amdgpu: use atomic operation to achieve lockless serialization

2026-05-19T16:11:34+00:00

In amdgpu_seq64_alloc there is a possibility that two difference cores
from two separate NODES can try to and could get the same free slot.
So this fixes that race here using atomic test_and_set clear operations.

Signed-off-by: Sunil Khatri 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
(cherry picked from commit 4d50a14d346141e03a7c3905e496d91e048bc30c)