Re: [PATCH v7 09/28] media: rockchip: rga: remove redundant rga_frame variables

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Integer overflow in crop rectangle validation allows out-of-bounds DMA access.
--

commit 33ab9b132f03dd68bd0a1628225764176f65c2db
Author: Sven Püschel <s.pueschel@pengutronix.de>

media: rockchip: rga: remove redundant rga_frame variables

This commit removes the redundant width, height, and colorspace
variables from the rga_frame struct. It replaces their usage with
the equivalent values already stored in the existing pix member.

> diff --git a/drivers/media/platform/rockchip/rga/rga.c b/drivers/media/platform/rockchip/rga/rga.c
> index c07207edffdb6..ca8d8a53dc251 100644
> --- a/drivers/media/platform/rockchip/rga/rga.c
> +++ b/drivers/media/platform/rockchip/rga/rga.c

[ ... ]

> @@ -629,8 +621,8 @@ static int vidioc_s_selection(struct file *file, void *priv,
>  		return -EINVAL;
>  	}
>  
> -	if (s->r.left + s->r.width > f->width ||
> -	    s->r.top + s->r.height > f->height ||
> +	if (s->r.left + s->r.width > f->pix.width ||
> +	    s->r.top + s->r.height > f->pix.height ||

[Severity: High]
This is a pre-existing issue, but can this crop rectangle validation
be bypassed via integer overflow?

Since s->r.left is an __s32 (checked to be >= 0) and s->r.width is an __u32,
could their sum wrap around? For example, if an attacker sets
s->r.left = 0x60000001 and s->r.width = 0x9FFFFFFF, the sum wraps to 0.
This would bypass the > f->pix.width check, and the huge width also passes
s->r.width < MIN_WIDTH.

Even with the rga_check_scaling mitigation, couldn't the bypass still work?

By setting the destination s->r.width = 0xA0000000 (and s->r.left = 0x60000000
to wrap), check_scaling_factor() evaluates src_size < dst_size
(0x9FFFFFFF < 0xA0000000) and computes src_size * hw->max_scaling_factor >= dst_size.
If max_scaling_factor is 8, 0x9FFFFFFF * 8 wraps around to 0xFFFFFFF8 in 32-bit
arithmetic, which evaluates to true and completely bypasses the scaling
bounds check.

Would the hardware then be programmed with (src_w - 1) & 0x1FFF
(e.g., 8190), causing the DMA engine to read/write 8190 pixels per line
and wildly exceed the actual V4L2 buffer allocation?

>  	    s->r.width < MIN_WIDTH || s->r.height < MIN_HEIGHT) {
>  		v4l2_dbg(debug, 1, &rga->v4l2_dev, "unsupported crop value.\n");
>  		return -EINVAL;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260521-spu-rga3-v7-0-3f33e8c7145f@pengutronix.de?part=9