From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: accel: ethosu: Handle possible underflow in IFM size calculations Date: Thu, 19 Feb 2026 09:57:31 +1000 Message-ID: In-Reply-To: <20260218-ethos-fixes-v1-3-be3fa3ea9a30@kernel.org> References: <20260218-ethos-fixes-v1-0-be3fa3ea9a30@kernel.org> <20260218-ethos-fixes-v1-3-be3fa3ea9a30@kernel.org> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review The fix changes `ifm_height` and `ifm_width` from `u32` to `s32` and adds an early check for negative values: > - u32 ifm_height = st->ofm.height[2] * stride_y + > + s32 ifm_height = st->ofm.height[2] * stride_y + > st->ifm.height[2] - (st->ifm.pad_top + st->ifm.pad_bottom); > - u32 ifm_width = st->ofm.width * stride_x + > + s32 ifm_width = st->ofm.width * stride_x + > st->ifm.width - (st->ifm.pad_left + st->ifm.pad_right); > > + if (ifm_height < 0 || ifm_width < 0) > + return -EINVAL; The arithmetic itself is worth examining. `st->ofm.height[2]` is `u16`, `stride_y` is `u32` (max value 4), `st->ifm.height[2]` is `u16`, and `pad_top`/`pad_bottom` are `u8`. The maximum positive value is roughly `0xFFFF * 4 + 0xFFFF = 327675`, which fits comfortably in `s32`. The minimum value when padding dominates is `0 + 0 - (255 + 255) = -510`, which is representable in `s32`. So the type change is safe. The values then get passed to `feat_matrix_length(info, &st->ifm, ifm_width, ifm_height, st->ifm.depth)` which takes `u32` parameters. Since the negative check happens before the call, only non-negative `s32` values reach the function, and the implicit conversion to `u32` is well-defined. No issues found. The commit message accurately describes the problem with padding values exceeding IFM dimensions and the mesa driver bug that triggered it. --- Generated by Claude Code Patch Reviewer