Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Potential out-of-bounds array access when indexing `node_id_to_phys_map` with unvalidated `entry->node_id`. -- commit 9ee6645118b792b4fedbe83c62cc09cc3bce36b1 Author: Andre Luiz Batista Bueno <[email protected]> drm/amdgpu: deduplicate JPEG v5.0 interrupt routine This commit deduplicates identical interrupt processing routines in jpeg_v5_0_1.c and jpeg_v5_0_2.c. It updates jpeg_v5_0_1_process_interrupt() to be non-static and calls it directly from the jpeg_v5_0_2 interrupt handlers to avoid code duplication. > 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 does this function lack bounds checking on entry->node_id before using it as an array index? When the interrupt vector is read from the hardware-writeable IH ring, entry->node_id can be an 8-bit value (0-255). Looking at how this is handled inside jpeg_v5_0_1_process_interrupt(): int jpeg_v5_0_1_process_interrupt(...) { u32 i, inst; i = node_id_to_phys_map[entry->node_id]; ... } Could a malicious or malfunctioning PCIe device supply an interrupt vector with a node_id >= NODEID_MAX (15), leading to an out-of-bounds read of up to 1020 bytes past the end of the node_id_to_phys_map array and a potential kernel panic? [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
