summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2014-01-29 17:01:42 +0100
committerwm4 <wm4@nowhere>2014-01-31 19:07:47 +0100
commit0801345d68a37ea9bbe1d77fd13c3cacce37723c (patch)
treec5a61bbdb92efec516b859a0a373b25519ebbe9f
parent5bd0fe5daf8ec20d309f3538bbf4da0735ba3879 (diff)
downloadmpv-0801345d68a37ea9bbe1d77fd13c3cacce37723c.tar.bz2
mpv-0801345d68a37ea9bbe1d77fd13c3cacce37723c.tar.xz
mp_image: reject too large image sizes
Larger sizes can introduce overflows, depending on the image format. In the worst case, something larger than 16000x16000 with 8 bytes per pixel will overflow 31 bits. Maybe there should be a proper failure path instead of a hard crash, but not yet. I imagine anything that sets a higher image size than a known working size should be forced to call a function to check the size (much like in ffmpeg/libavutil).
-rw-r--r--video/mp_image.c4
1 files changed, 4 insertions, 0 deletions
diff --git a/video/mp_image.c b/video/mp_image.c
index b0f174d769..44ee0cfedb 100644
--- a/video/mp_image.c
+++ b/video/mp_image.c
@@ -175,6 +175,10 @@ static int mp_chroma_div_up(int size, int shift)
// Caller has to make sure this doesn't exceed the allocated plane data/strides.
void mp_image_set_size(struct mp_image *mpi, int w, int h)
{
+ // av_image_check_size has similar checks and triggers around 16000*16000
+ if (w >= (1 << 14) || h >= (1 << 14) || w < 0 || h < 0)
+ abort();
+
mpi->w = mpi->display_w = w;
mpi->h = mpi->display_h = h;
for (int n = 0; n < mpi->num_planes; n++) {