Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Missing bounds check on `entry->node_id` before array indexing on `node_id_to_phys_map` can lead to an out-of-bounds memory read. -- commit 18102389ca6554c76ab0eea5128ed6304f9d3003 Author: Andre Luiz Batista Bueno <[email protected]> drm/amdgpu: deduplicate JPEG v5.0 interrupt routine Both jpeg_v5_0_1.c and jpeg_v5_0_2.c implement identical interrupt processing routines. To avoid code duplication, make the implementation in jpeg_v5_0_1.c non-static and call it directly from jpeg_v5_0_2.c. > diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v5_0_1.c > b/drivers/gpu/drm/amd/amdgpu/jpeg_v5_0_1.c > index 250316704dfac..2b8d8f4ca30d2 100644 > --- a/drivers/gpu/drm/amd/amdgpu/jpeg_v5_0_1.c > +++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v5_0_1.c > @@ -755,7 +755,7 @@ static int jpeg_v5_0_1_set_ras_interrupt_state(struct > amdgpu_device *adev, > > > > -static int jpeg_v5_0_1_process_interrupt(struct amdgpu_device *adev, > +int jpeg_v5_0_1_process_interrupt(struct amdgpu_device *adev, > struct amdgpu_irq_src *source, > struct amdgpu_iv_entry *entry) > { [Severity: High] This is a pre-existing issue, but since this function is being exported to be shared by other JPEG v5.0 blocks, could an out-of-bounds array access occur here? Looking at the beginning of jpeg_v5_0_1_process_interrupt(): u32 i, inst; i = node_id_to_phys_map[entry->node_id]; The entry->node_id is extracted from the GPU's Interrupt Ring buffer using an 8-bit mask, allowing values up to 255. However, node_id_to_phys_map is defined globally with a fixed size of NODEID_MAX (15 elements). Without a bounds check verifying entry->node_id < NODEID_MAX before indexing the array, could a malformed hardware interrupt payload cause the driver to read out-of-bounds memory? [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
