[HIGH] [SDL #8281] Possible overflow in SDL_SW_UpdateYUVTexture

[Chevalier12]

Tracking upstream SDL issue libsdl-org#8281

• Priority: HIGH — provisional triage from SDL-OPEN-ISSUES-PRIORITIES.md, NOT an official SDL severity.
• Source: Possible overflow in SDL_SW_UpdateYUVTexture libsdl-org/SDL#8281
• Original title: Possible overflow in SDL_SW_UpdateYUVTexture
• Reported by: tntnkn
• Upstream state at capture: open; state reason:
• Created: 2023-09-23T11:01:04.0000000Z; updated: 2024-10-06T17:37:00.0000000Z
• Snapshot captured: 2026-09-07T17:43:47.7634460Z
• Upstream labels:
• Upstream milestone (not affected versions): 3.x (https://github.com/libsdl-org/SDL/milestone/6)
• Upstream assignees:
• Upstream comments included: 2
• Locked: False; lock reason:
• Triage rationale: Posibil overflow în dimensiunea copiei YUV; verificați limitele și accesul la memorie, fără vulnerabilitate confirmată.

This is an attributed tracking copy, not a locally reproduced or confirmed Graphix defect. Applicability, affected versions and ownership still require validation. No automatic synchronization or resolution is implied. Original descriptions and comments are preserved literally in Markdown code blocks to avoid notifying mentioned users or resolving SDL references against Graphix. Attachments, logs, patches and other linked resources remain at their original URLs; external resource contents and edit/event histories are not copied.

Graphix validation checklist

• Read the current upstream issue and discussion.
• Establish affected versions/platforms and whether Graphix is affected.
• Reproduce the reported behavior and identify the invariant owner.
• Implement an ownership-correct fix or document an upstream/external resolution.
• Verify regression coverage and applicable platform/runtime gates.

Original description

Casting to `size_t` in [this piece](https://github.com/libsdl-org/SDL/blob/6a381567b0412603054e3ecd77916085edffe94a/src/render/SDL_yuv_sw.c#L124) makes little sense as the expression being cast may (theoretically) overflow. 

The safer code may be:

```c
	SDL_memcpy(swdata->pixels, pixels,
	         (size_t)swdata->h * (size_t)swdata->w + 2 * (size_t)((swdata->h + 1) / 2) * (size_t)((swdata->w + 1) / 2));
```
Taking into account that these are texture dimensions, as I may understand, the overflow seems unlikely to happen.

Original discussion (chronological)

Original comment by slouken

Source: libsdl-org#8281 (comment)
Created: 2023-09-25T16:08:31.0000000Z; updated: 2023-09-25T16:08:31.0000000Z; association: COLLABORATOR

We have an overflow checking function `SDL_size_mul_overflow()` that should probably be used here.

Original comment by slouken

Source: libsdl-org#8281 (comment)
Created: 2024-10-06T17:36:56.0000000Z; updated: 2024-10-06T17:36:56.0000000Z; association: COLLABORATOR

We are scoping work for the SDL 3.2.0 release, so please let us know if this is a showstopper for you.