Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] amdgpu_ras_global_ras_isr and amdgpu_ras_reset_gpu dereference ras without checking if it is NULL. -- commit 968ac5f5bc519258a8c9858799f60257d1c4fa96 Author: Dmitriy Chumachenko <[email protected]> drm/amdgpu: check ras and obj before dereference This patch adds NULL checks for the ras and obj pointers in nbio_v7_9_handle_ras_controller_intr_no_bifring() before dereferencing them. This prevents a hard-IRQ context crash during the initialization window where the fatal-error interrupt is enabled but the RAS context is not fully created. > diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c > b/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c > index bdfd2917e3cab..def02993b7cfd 100644 > --- a/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c > +++ b/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c > @@ -535,7 +535,7 @@ static void > nbio_v7_9_handle_ras_controller_intr_no_bifring(struct amdgpu_device > RAS_CNTLR_INTERRUPT_CLEAR, 1); > WREG32_SOC15(NBIO, 0, regBIF_BX0_BIF_DOORBELL_INT_CNTL, > bif_doorbell_intr_cntl); > > - if (!ras->disable_ras_err_cnt_harvest) { > + if (ras && !ras->disable_ras_err_cnt_harvest && obj) { [Severity: High] This isn't a bug introduced by this patch, but while this change fixes the NULL pointer dereference here, it looks like there are similar vulnerabilities in other interrupt handlers during this same initialization window. If the ATHUB interrupt fires when the RAS context is unavailable, its handler delegates to amdgpu_ras_global_ras_isr(), which fetches the RAS context via amdgpu_ras_get_context() but unconditionally dereferences it: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:amdgpu_ras_global_ras_isr() { ... ras->gpu_reset_flags |= AMDGPU_RAS_GPU_RESET_MODE1_RESET; ... } It then calls amdgpu_ras_reset_gpu(), which also uses the ras pointer without a NULL check: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:amdgpu_ras_reset_gpu() { ... if (atomic_cmpxchg(&ras->in_recovery, 0, 1) == 0) { ... } Both direct dereferences will cause a hard-IRQ context kernel panic if ras is NULL. Should these paths also include a check for the RAS context? > /* > * clear error status after ras_controller_intr > * according to hw team and count ue number -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
