1
0
mirror of https://github.com/mpv-player/mpv synced 2025-01-05 06:30:06 +00:00

draw_bmp: ensure last slice is less than total width (again)

Essentially the same as d1d2370d07 except
for clear_rgba_overlay. From some empirical testing, the s->x1 value is
either 0 or SLICE_W (256). In the case where it is 256 and s->x0 is 0,
then it writes memory. For most slices, this is fine. However for the
very last slice in the loop, it is possible for the width here to exceed
the total width of the line (p->w). If that occurs, the memset triggers
a buffer overflow. This last case needs to be guarded in the same way as
the previously mentioned commit (total width - SLICE_W * x) and with
MPMIN in case s->x1 is 0 here to preserve the old behavior. It's unknown
if anything other than dmabuf-wayland can possibly hit this, but it's
definitely a problem within mp_draw_sub_overlay itself.
This commit is contained in:
Dudemanguy 2023-07-03 16:00:56 -05:00
parent c958990833
commit f3c1dcf7a1

View File

@ -485,6 +485,10 @@ static void clear_rgba_overlay(struct mp_draw_sub_cache *p)
for (int sx = 0; sx < p->s_w; sx++) { for (int sx = 0; sx < p->s_w; sx++) {
struct slice *s = &line[sx]; struct slice *s = &line[sx];
// Ensure this final slice doesn't extend beyond the width of p->s_w
if (s->x1 == SLICE_W && sx == p->s_w - 1 && y == p->rgba_overlay->h - 1)
s->x1 = MPMIN(p->w - ((p->s_w - 1) * SLICE_W), s->x1);
if (s->x0 <= s->x1) { if (s->x0 <= s->x1) {
memset(px + s->x0, 0, (s->x1 - s->x0) * 4); memset(px + s->x0, 0, (s->x1 - s->x0) * 4);
*s = (struct slice){SLICE_W, 0}; *s = (struct slice){SLICE_W, 0};