Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] drm: heap buffer overflow in drm_fb_xrgb8888_to_uyvy_line() on odd clip width --
commit 4e505b4602c1fdbf4570529c2dce5fc08ba8b249 Author: Ho Jie Feng <[email protected]> Subject: drm/format-helper: Add XRGB8888 to UYVY conversion This commit adds a new format helper function, drm_fb_xrgb8888_to_uyvy(), to convert XRGB8888 framebuffers to UYVY format. It is intended for devices that use packed UYVY natively but need to support XRGB8888 framebuffers. > diff --git a/drivers/gpu/drm/drm_format_helper.c > b/drivers/gpu/drm/drm_format_helper.c > index 6cddf05c493bd..606733ca43fb4 100644 > --- a/drivers/gpu/drm/drm_format_helper.c > +++ b/drivers/gpu/drm/drm_format_helper.c [ ... ] > +static void drm_fb_xrgb8888_to_uyvy_line(void *dbuf, const void *sbuf, > unsigned int width) > +{ > + u8 *transfer_buffer = dbuf; > + const __le32 *temp_buffer = sbuf; > + unsigned int i, dst_offset = 0; > + unsigned int pixel1, pixel2; > + unsigned int r1, g1, b1, r2, g2, b2; > + unsigned int r, g, b; > + unsigned int v, y1, u, y2; > + > + for (i = 0; i < width; i += 2) { > + pixel1 = le32_to_cpup(&temp_buffer[i]); > + pixel2 = le32_to_cpup(&temp_buffer[i + 1]); [Severity: High] Does this code perform an out-of-bounds read if the damage clip width is odd? If userspace provides a damage clip where the width is an odd number, on the final iteration of this loop, it appears we will unconditionally read temp_buffer[i + 1] past the end of the source buffer. > + > + r1 = (pixel1 & 0x00ff0000) >> 16; > + g1 = (pixel1 & 0x0000ff00) >> 8; > + b1 = pixel1 & 0x000000ff; > + r2 = (pixel2 & 0x00ff0000) >> 16; > + g2 = (pixel2 & 0x0000ff00) >> 8; > + b2 = pixel2 & 0x000000ff; > + > + y1 = drm_pixel_rgb_to_y_bt601(r1, g1, b1); > + y2 = drm_pixel_rgb_to_y_bt601(r2, g2, b2); > + > + r = r1 + r2; > + g = g1 + g2; > + b = b1 + b2; > + > + v = drm_pixel_rgb2_to_v_bt601(r, g, b); > + u = drm_pixel_rgb2_to_u_bt601(r, g, b); > + > + transfer_buffer[dst_offset++] = u; > + transfer_buffer[dst_offset++] = y1; > + transfer_buffer[dst_offset++] = v; > + transfer_buffer[dst_offset++] = y2; [Severity: High] Can this write overflow the destination buffer boundary? Since the destination line buffer size is calculated based on dst_pixsize = 2, it expects 2 bytes per pixel. For an odd width, writing a 4-byte UYVY macropixel (u, y1, v, y2) on the final iteration writes 4 bytes when only 2 bytes are expected for that final odd pixel. This appears to overflow the destination buffer by 2 bytes per line, potentially corrupting adjacent lines or causing a kernel heap buffer overflow on the final line. > + } > +} [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
