Re: [PATCH 1/2] drm/v3d: validate copy-query buffer bounds against destination BO size

[Michael Bommarito]

On Sun, Jun 14, 2026 at 4:12 PM Maíra Canal <mcanal@xxxxxxxxxx> wrote:

> If you are doing it for V3D_CPU_JOB_TYPE_COPY_TIMESTAMP_QUERY and
> V3D_CPU_JOB_TYPE_COPY_PERFORMANCE_QUERY, you should also do it for
> V3D_CPU_JOB_TYPE_TIMESTAMP_QUERY and
> V3D_CPU_JOB_TYPE_RESET_TIMESTAMP_QUERY.

OK, will do!

> How could this ever overflow? slots is 1 or 2; elem is 4 or 8. The
> maximum product is 2 * 8 = 16. That cannot overflow any integer type.
> ...
>      if (tquery->queries[i].offset + sizeof(u64) > src->base.base.size)

You were definitely right about the first check being overkill, but I
think we do need to think about 32-bit for this spot.  Let me  know in
v2 if I missed something

> About your second patch (the KUnit reproducer), it's a nice test to
> reproduce this issue, but for me, it's a no-go in terms of upstreaming.
> This is a very simple issue, not related to any v3d functional
> regression. So, I'd prefer not to take the KUnit test to the branch.
> Regarding this fix, a v2 addressing the issues pointed out is welcome.

Sounds good.  I am trying to send them by default after getting yelled
at by Greg for not including unit tests in every patch he sees :)

V2 coming up soon

Thanks,
Mike