Debian-LTS has issued an advisory on January 30: https://www.debian.org/lts/security/2021/dla-2536 The issue is fixed upstream in 2.0.14 in this commit: https://hg.libsdl.org/SDL/rev/3f9b4e92c1d9
Cauldron is already at sdl2-2.0.14-1.mga8.src.rpm. Assigning to DavidG after recent commits to this SRPM.
Assignee: bugsquad => geiger.david68210
Fedora has issued an advisory for this today (February 6): https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/5FS32YCEJLQ2FYUWSWYI2ZMQWQEAWJNR/
CC: (none) => rverschelde
The patch does not apply on current sdl2-2.0.10-1.mga7 package but apply in 2.0.12 release, so what should we do? update to 2.0.12 + upstream patch? update to 2.0.14?
The patch was easy enough to rediff against 2.0.10, the code only changed one one line: http://svnweb.mageia.org/packages?view=revision&revision=1720410 Advisory: ========= Updated sdl2 packages fix security vulnerabilities This update fixes two security vulnerabilities which could result in heap corruption or over-read with crafted .BMP files (CVE-2020-14409, CVE-2020-14410). References: - https://security-tracker.debian.org/tracker/CVE-2020-14409 - https://security-tracker.debian.org/tracker/CVE-2020-14410 - https://github.com/libsdl-org/SDL/commit/a7ff6e96155f550a5597621ebeddd03c98aa9294 SRPMs in core/updates_testing: ============================= sdl2-2.0.10-1.1.mga7 mingw-SDL2-2.0.10-1.1.mga7 RPMs in core/updates_testing: ============================= lib64sdl2.0_0-2.0.10-1.1.mga7 lib64sdl2.0-devel-2.0.10-1.1.mga7 lib64sdl2.0-static-devel-2.0.10-1.1.mga7 sdl2-docs-2.0.10-1.1.mga7 mingw32-SDL2-2.0.10-1.1.mga7 mingw32-SDL2-static-2.0.10-1.1.mga7 mingw64-SDL2-2.0.10-1.1.mga7 mingw64-SDL2-static-2.0.10-1.1.mga7
CC: (none) => geiger.david68210Assignee: geiger.david68210 => qa-bugs
mga7, x86_64 Could not find any PoC files for the two CVEs. Tried compiling and executing a loopwave.c file from a previous test. There were complaints but an executable binary was generated. $ file loopwave loopwave: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=c8edbba31dc2729218e668d8825c9f8c6113bc72, for GNU/Linux 3.2.0, with debug_info, not stripped $ ./loopwave Semiramis.wav Using audio driver: (null) In pavucontrol: loopwave: Simple DirectMedia Layer on That goes on forever, as designed. $ urpmq --whatrequires lib64sdl2.0_0 | sort -u That produced a lot of output. Many games seem to use it and also blender. blender works anyway before updating. Updated all the packages including mingw*. $ gcc -o loopwave -I/usr/include/SDL2 $(pkg-config --libs sdl2) loopwave.c loopwave.c: In function ‘main’: loopwave.c:88:60: warning: passing argument 1 of ‘SDL_GetAudioDeviceName’ makes integer from pointer without a cast [-Wint-conversion] printf("Using audio driver: %s\n", SDL_GetAudioDeviceName(name, 32)); ^~~~ In file included from /usr/include/SDL2/SDL.h:36, from loopwave.c:12: /usr/include/SDL2/SDL_audio.h:359:37: note: expected ‘int’ but argument is of type ‘char *’ extern DECLSPEC const char *SDLCALL SDL_GetAudioDeviceName(int index, ^~~~~~~~~~~~~~~~~~~~~~ $ ll loopwave -rwxr-xr-x 1 lcl lcl 21360 Apr 29 20:38 loopwave* $ date Thu 29 Apr 20:40:02 BST 2021 Played a WAV file in a loop using loopwave as before. No change in behaviour. So clean updates, no regressions in the API within the simple bounds tested here, so that is two plus marks. Not convinced that simply running blender and playing with the interface at a simple level would demonstrate use of SDL so shall skip that apart from launching and closing blender. Played a WAV file using mpv under strace. $ grep -i SDL wav.trace openat(AT_FDCWD, "/lib64/libSDL2-2.0.so.0", O_RDONLY|O_CLOEXEC) = 3 Giving this an OK for 64-bits, conveniently forgetting mingw.
CC: (none) => tarazed25Whiteboard: (none) => MGA7-64-OK
Validating. Advisory committed.
Keywords: (none) => advisoryCVE: (none) => CVE-2020-14409, CVE-2020-14410CC: (none) => ouaurelien
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0201.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED