Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Potential 1-byte out-of-bounds read past the heap buffer in `ssd132x_update_rect` when device width is configured to an odd value. -- commit de1c71cf327dfb3f916baab562b7b1c9945af5e9 Author: Amit Barzilai <[email protected]> drm/ssd130x: fix column and row end address in partial updates for ssd132x This commit corrects the relative end addresses used in the "Set Column Address" and "Set Row Address" commands for SSD132X controllers during partial screen updates. It ensures that the absolute addresses are correctly calculated and sent to the controller. Cc: [email protected] > diff --git a/drivers/gpu/drm/solomon/ssd130x.c > b/drivers/gpu/drm/solomon/ssd130x.c > --- a/drivers/gpu/drm/solomon/ssd130x.c > +++ b/drivers/gpu/drm/solomon/ssd130x.c [ ... ] > @@ -864,12 +864,13 @@ static int ssd132x_update_rect(struct ssd130x_device > *ssd130x, > */ > > /* Set column start and end */ > - ret = ssd130x_write_cmd(ssd130x, 3, SSD132X_SET_COL_RANGE, x / > segment_width, columns - 1); > + ret = ssd130x_write_cmd(ssd130x, 3, SSD132X_SET_COL_RANGE, x / > segment_width, > + x / segment_width + columns - 1); > if (ret < 0) > return ret; > > /* Set row start and end */ > - ret = ssd130x_write_cmd(ssd130x, 3, SSD132X_SET_ROW_RANGE, y, rows - 1); > + ret = ssd130x_write_cmd(ssd130x, 3, SSD132X_SET_ROW_RANGE, y, y + rows > - 1); > if (ret < 0) > return ret; > > for (i = 0; i < height; i++) { > /* Process pair of pixels and combine them into a single byte */ > for (j = 0; j < width; j += segment_width) { > u8 n1 = buf[i * width + j]; > u8 n2 = buf[i * width + j + 1]; [Severity: High] This is a pre-existing issue, but could this loop read out of bounds if the device tree specifies an odd solomon,width (e.g., 129)? If the device width is configured to an odd value, the update rectangle's width can also be odd. The buffer array is allocated in ssd132x_primary_plane_atomic_check() with exactly pitch * height bytes (where pitch equals width). During the last iteration of the final row, j + 1 would evaluate to width. This causes the n2 assignment to access buf[height * width], which is one byte past the requested allocation size. Can this trigger a KASAN out-of-bounds read warning or scramble display output on odd-width panels by reading across row boundaries? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
