Re: [PATCH] drm/format-helper: Add XRGB8888 to UYVY conversion

[sashiko-bot@kernel.org]

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 <hjf3108@gmail.com>
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/20261012170857.199561-1-hjf3108@gmail.com?part=1