Sat, 08 Jun 2019 19:02:42 -0700Fixed bug 3894 - Fuzzing crashes for SDL_LoadWAV
Sam Lantinga [Sat, 08 Jun 2019 19:02:42 -0700] rev 12806
Fixed bug 3894 - Fuzzing crashes for SDL_LoadWAV

Simon Hug

I had a look at this and made some additions to SDL_wave.c.

The attached patch adds many checks and error messages. For some reason I also added A-law and µ-law decoders. Forgot exactly why... but hey, they're small.

The WAVE format is seriously underspecified (at least by the documents that are publicly available on the internet) and it's a shame Microsoft never put something better out there. The language used in them is so loose at times, it's not surprising the encoders and decoders behave very differently. The Windows Media Player doesn't even support MS ADPCM correctly.

The patch also adds some hints to make the decoder more strict at the cost of compatibility with weird WAVE files.

I still think it needs a bit of cleaning up (Not happy with the MultiplySize function. Don't like the name and other SDL code may want to use something like this too.) and some duplicated code may be folded together. It does work in this state and I have thrown all kinds of WAVE files at it. The AFL files also pass with it and some even play (obviously just noise). Crafty little fuzzer.

Any critique would be welcome. I have a fork of SDL with a audio-loadwav branch over here if someone wants to use the commenting feature of Bitbucket:

https://bitbucket.org/ChliHug/SDL

I also cobbled some Lua scripts together to create WAVE test files:

https://bitbucket.org/ChliHug/gendat

Sat, 08 Jun 2019 18:40:11 -0700Fixed bug 4041 - Android, SDL_Renderer OpenGLES 1 is loading GLESv2 library
Sam Lantinga [Sat, 08 Jun 2019 18:40:11 -0700] rev 12805
Fixed bug 4041 - Android, SDL_Renderer OpenGLES 1 is loading GLESv2 library

Sylvain

On Android, if you set no attribute using SDL_GL_SetAttribute(), and try to create a SDL Render OpenGLES 1:

- it loads first by default GLESv2 libraries
- creates the rendere OpenGLES 1
- recreates the Window to have a context 1.1 ( https://hg.libsdl.org/SDL/file/00fb5966c44f/src/render/opengles/SDL_render_gles.c#l298 )

But it doesn't unload libraries, then reload GLESv1 lib. So the SDL_Renderer OpenGLES 1 is working with GLES 2 libs, which seems inconsistent.


If you, at first, set
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 1);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 1);
It will correctly load GLES v1 libraries.

Here's a small patch to reload egl libs when SDL_RecreateWindow() is called.
It fixes the issue, also the case from bug 4042

( SDL_RecreateWindow() is used by SDL_Renderer gl, gles1, gles2. )

Sat, 08 Jun 2019 18:32:29 -0700Temporary fix for bug 4254 - a _lot_ of strict aliasing warnings
Sam Lantinga [Sat, 08 Jun 2019 18:32:29 -0700] rev 12804
Temporary fix for bug 4254 - a _lot_ of strict aliasing warnings

Ozkan Sezer

A horde of strict aliasing violation warnings are emitted from joystick
layer, and also from a few other places. This happens with gcc-4.4.7 on
Linux CentOS 6.10. Some other sysjoystick would possibly have the same
warnings.

Attached my full log here. Example entry:
src/joystick/SDL_joystick.c: In function 'SDL_GetJoystickGUIDInfo':
src/joystick/SDL_joystick.c:1094: warning: dereferencing pointer '({anonymous})' does break strict-aliasing rules

Sat, 08 Jun 2019 18:22:18 -0700Fixed bug 4294 - Audio: perform more validation on conversion request
Sam Lantinga [Sat, 08 Jun 2019 18:22:18 -0700] rev 12803
Fixed bug 4294 - Audio: perform more validation on conversion request

janisozaur

There are many cases which are not able to be handled by SDL's audio conversion routines, including too low (negative) rate, too high rate (impossible to allocate).

This patch aims to report such issues early and handle others in a graceful manner. The "INT32_MAX / RESAMPLER_SAMPLES_PER_ZERO_CROSSING" value is the conservative approach in terms of what can _technically_ be supported, but its value is 4'194'303, or just shy of 4.2MHz. I highly doubt any sane person would use such rates, especially in SDL2, so I would like to drive this limit further down, but would need some assistance to do that, as doing so would have to introduce an arbitrary value. Are you OK with such approach? What would a good value be? Wikipedia (https://en.wikipedia.org/wiki/High-resolution_audio) lists 96kHz as the highest sampling rate in use, even if I quadruple it for a good measure, to 384kHz it's still an order of magnitude lower than 4MHz.

Sat, 08 Jun 2019 18:07:58 -0700CVE-2019-7578: Fix a buffer overread in InitIMA_ADPCM
Sam Lantinga [Sat, 08 Jun 2019 18:07:58 -0700] rev 12802
CVE-2019-7578: Fix a buffer overread in InitIMA_ADPCM
If IMA ADPCM format chunk was too short, InitIMA_ADPCM() parsing it
could read past the end of chunk data. This patch fixes it.

CVE-2019-7578
https://bugzilla.libsdl.org/show_bug.cgi?id=4494

Signed-off-by: Petr Písař <ppisar@redhat.com>

Sat, 08 Jun 2019 18:02:09 -0700CVE-2019-7578: Fix a buffer overread in InitIMA_ADPCM SDL-1.2
Petr Písař [Sat, 08 Jun 2019 18:02:09 -0700] rev 12801
CVE-2019-7578: Fix a buffer overread in InitIMA_ADPCM
If IMA ADPCM format chunk was too short, InitIMA_ADPCM() parsing it
could read past the end of chunk data. This patch fixes it.

CVE-2019-7578
https://bugzilla.libsdl.org/show_bug.cgi?id=4494

Signed-off-by: Petr Písař <ppisar@redhat.com>

Sat, 08 Jun 2019 17:57:43 -0700CVE-2019-7572: Fix a buffer overread in IMA_ADPCM_nibble SDL-1.2
Petr Písař [Sat, 08 Jun 2019 17:57:43 -0700] rev 12800
CVE-2019-7572: Fix a buffer overread in IMA_ADPCM_nibble
If an IMA ADPCM block contained an initial index out of step table
range (loaded in IMA_ADPCM_decode()), IMA_ADPCM_nibble() blindly used
this bogus value and that lead to a buffer overread.

This patch fixes it by moving clamping the index value at the
beginning of IMA_ADPCM_nibble() function instead of the end after
an update.

CVE-2019-7572
https://bugzilla.libsdl.org/show_bug.cgi?id=4495

Signed-off-by: Petr Písař <ppisar@redhat.com>

Sat, 08 Jun 2019 17:43:23 -0700Fixed bug 4526 - replace SDL_RW* macros with functions for using in bindings
Sam Lantinga [Sat, 08 Jun 2019 17:43:23 -0700] rev 12799
Fixed bug 4526 - replace SDL_RW* macros with functions for using in bindings

ace

I got this bug in SDL_ttf:
https://bugzilla.libsdl.org/show_bug.cgi?id=4524
Sylvain proposed solution:
SDL_RWseek(RWops, 0, RW_SEEK_SET);

And it works, but i can use it my project, because it written in C# with SDL2-CS wrapper and there not export for macroses:
#define SDL_RWsize(ctx) (ctx)->size(ctx)
#define SDL_RWseek(ctx, offset, whence) (ctx)->seek(ctx, offset, whence)
#define SDL_RWtell(ctx) (ctx)->seek(ctx, 0, RW_SEEK_CUR)
#define SDL_RWread(ctx, ptr, size, n) (ctx)->read(ctx, ptr, size, n)
#define SDL_RWwrite(ctx, ptr, size, n) (ctx)->write(ctx, ptr, size, n)
#define SDL_RWclose(ctx) (ctx)->close(ctx)

Therefore, I suggest replacing this macros with functions so that they can be exported and used in bindings

Sat, 08 Jun 2019 15:10:20 -0700Fixed bug 4533 - Update ANGLE to load d3dcompiler_47.dll instead of d3dcompiler_46.dll
Sam Lantinga [Sat, 08 Jun 2019 15:10:20 -0700] rev 12798
Fixed bug 4533 - Update ANGLE to load d3dcompiler_47.dll instead of d3dcompiler_46.dll

msmshazan

Update ANGLE Libraries to support d3dcompiler_47.dll since chrome does not ship with d3dcompiler_46.dll and d3dcompiler_43.dll

Mon, 04 Mar 2019 12:16:43 -0500cocoa: Fix assert to use SDL_assert
Ethan Lee [Mon, 04 Mar 2019 12:16:43 -0500] rev 12797
cocoa: Fix assert to use SDL_assert