draw_bmp: ensure last slice width is less than total width

e97819f88e451623a397b79d101497205fe849f9 corrected a special case
condition that lead to an out of bounds access if the total width
happened to be an integer multiple of SLICE_W (256) which could cause a
crash in software VOs. However, it turns out that the functions in this
file evaluate quite differently when using encoding mode (and presumably
libmpv as well according to reports although I could not independently
verify it).

The logic here gets complicated but what ends up happening is that, in
blend_overlay_with_video, the value of x + w can be greater than p->w in
certain cases in encoding mode. The x is the positional value of the
slice which remained unchanged from before, but w can take the full
value of SLICE_W (256) which is not necessarily correct. The width of
the final slice here should be the total remaining width. We can handle
this in mark_rect by simply always adjusting x1 of the last slice to be
equal to total width - SLICE_W * x so it can never extend beyond where
it should be. In practice, this value should be the maximum allowed
here. I'm not sure if the existing x1 value can possibly already be
lower than SLICE_W, but just MPMIN it to be on the safe side.
Fixes #10908.

1 files changed, 5 insertions, 0 deletions

diff --git a/sub/draw_bmp.c b/sub/draw_bmp.c
index 2765ceb759..78ce773822 100644
--- a/sub/draw_bmp.c
+++ b/sub/draw_bmp.c
@@ -283,6 +283,11 @@ static void mark_rect(struct mp_draw_sub_cache *p, int x0, int y0, int x1, int y
             }
         }
 
+        // Ensure the very last slice does not extend
+        // beyond the total width.
+        struct slice *last_s = &line[p->s_w - 1];
+        last_s->x1 = MPMIN(p->w - ((p->s_w - 1) * SLICE_W), last_s->x1);
+
         p->any_osd = true;
     }
 }