We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Both SDL-1.2 and SDL-2.0 hg versions of SDL_LoadBMP() succeed,
however SDL-2.0 fails in SDL_PixelFormatEnumToMasks() whereas
SDL-1.2 crashes.

This is a fuzz file, yes? SDL_LoadBMP() should have rejected
the file in the first place..

This file gives biWidth = -1.  So a quick fix would be something like:

diff --git a/src/video/SDL_bmp.c b/src/video/SDL_bmp.c
--- a/src/video/SDL_bmp.c
+++ b/src/video/SDL_bmp.c
@@ -143,6 +143,11 @@ SDL_Surface * SDL_LoadBMP_RW (SDL_RWops 
 	(void) biYPelsPerMeter;
 	(void) biClrImportant;
 
+	if (biWidth < 0) {
+		SDL_SetError("BMP file with negative width");
+		was_error = SDL_TRUE;
+		goto done;
+	}
 	if (biHeight < 0) {
 		topDown = SDL_TRUE;
 		biHeight = -biHeight;

If this is acceptable, this should be applied to SDL2.0 too, and also
to SDL_image 1.2 and 2.0 versions.

Ryan, Sam?

(In reply to Ozkan Sezer from comment #2)
> This file gives biWidth = -1.  So a quick fix would be something like:

While we are there, we should probably reject zero width or height too.
Something like:

diff --git a/src/video/SDL_bmp.c b/src/video/SDL_bmp.c
--- a/src/video/SDL_bmp.c
+++ b/src/video/SDL_bmp.c
@@ -224,10 +224,15 @@ SDL_LoadBMP_RW(SDL_RWops * src, int free
         headerSize = (Uint32) (SDL_RWtell(src) - (fp_offset + 14));
         if (biSize > headerSize) {
             SDL_RWseek(src, (biSize - headerSize), RW_SEEK_CUR);
         }
     }
+    if (biWidth <= 0 || biHeight == 0) {
+        SDL_SetError("BMP file with bad dimensions (%dx%d)", biWidth, biHeight);
+        was_error = SDL_TRUE;
+        goto done;
+    }
     if (biHeight < 0) {
         topDown = SDL_TRUE;
         biHeight = -biHeight;
     } else {
         topDown = SDL_FALSE;


Ryan, Sam: is this correct?  OK to apply to SDL and SDL_image to both 1.2
and 2.0 branches?

(Sorry if you get several emails like this, we're marking a bunch of bugs.)

We're hoping to ship SDL 2.0.11 on a much shorter timeframe than we have historically done releases, so I'm starting to tag bugs we hope to have closed in this release cycle.

Note that this tag means we just intend to scrutinize this bug for the 2.0.11 release: we may fix it, reject it, or even push it back to a later release for now, but this helps give us both a goal and a wishlist for the next release.

If this bug has been quiet for a few months and you have new information (such as, "this is definitely still broken" or "this got fixed at some point"), please feel free to retest and/or add more notes to the bug.

--ryan.

Fixed, thanks!
https://hg.libsdl.org/SDL/rev/e7ba650a643a

Fix applied to SDL-1.2 branches, too:
https://hg.libsdl.org/SDL/rev/ad1bbfbca760
https://hg.libsdl.org/SDL_image/rev/a59bfe382008

This was assigned CVE-2019-13616

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.