SDL (Simple DirectMedia Layer) through 2.0.12 has an Integer Overflow (and resultant SDL_memcpy heap corruption) in SDL_BlitCopy in video/SDL_blit_copy.c via a crafted .BMP file. Reference: https://bugzilla.libsdl.org/show_bug.cgi?id=5200
Created SDL tracking bugs for this issue: Affects: fedora-all [bug 1920457]
Didn't you mistaken SDL with SDL2? The linked patch is for SDL2 and it makes sure that calculating int surface->pitch in SDL_CreateRGBSurfaceWithFormat() does not overflow and thus that any subsequent memory allocation and access based on the pitch and surface->width and surface->height are correct. SDL we have in Fedora and RHEL and upstream has is already hardened: SDL_CreateRGBSurface() makes sure that width and height fits into unsigned 16-bit integer and SDL_CalculatePitch() makes sure that the pitch computation also fits into unsigned 16-bit integer (surface-pitch is Uint16 type there). The multiplication at SDL_malloc(surface->h*surface->pitch) in SDL_CreateRGBSurface() cannot overflow because the argument has size_t type which is not shorter than unsigned 32-bit on any Fedora and RHEL supported platform. Therefore I think SDL is not vulnerable. Do you have a counter example? Or at least reproducer for the original SDL2 bug?
Created SDL2 tracking bugs for this issue: Affects: epel-7 [bug 1921358] Affects: fedora-all [bug 1921356] Created mingw-SDL2 tracking bugs for this issue: Affects: fedora-all [bug 1921357]
Upstream patch: https://hg.libsdl.org/SDL/rev/3f9b4e92c1d9
Seems to be quite similar to CVE-2017-2888.
The upstream patch https://hg.libsdl.org/SDL/rev/3f9b4e92c1d9 for CVE-2020-14409 corrects computing pitch and changes SDL_COMPILE_TIME_ASSERT() macro. But the next commit reverts the SDL_COMPILE_TIME_ASSERT() change as unnecessary. Thus CVE-2020-14409 is only about computing the pitch in SDL2. The same pitch bug in SDL has already been reported and fixed as CVE-2019-7637. CVE-2017-2888 fixed related integer overflows when allocating the pixels memory.
Statement: SDL as shipped in Red Hat Enterprise Linux 6, 7, and 8 is not affected as the vulnerable code exists in SDL2; SDL is already hardened for this flaw.