TALOS has issued an advisory on October 10: https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0395 Note that fixing the issue requires adjusting compiler flags, in addition to patching, according to the RedHat bug for this issue: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-2888 Mageia 5 and Mageia 6 are also affected.
Whiteboard: (none) => MGA6TOO, MGA5TOO
Source RPM: sdl2-2.0.6-1.mga7.src.rpm => sdl2-2.0.6-1.mga7, mingw-SDL2-2.0.5-1.mga6
The flags change should not be needed with the additional upstream fix I'm backporting: - http://hg.libsdl.org/SDL/rev/7e0f1498ddb5 - http://hg.libsdl.org/SDL/rev/81a4950907a0
Fixed in Cauldron and fixed packages pushed for mga6, still need to rediff the patch against SDL 2.0.3 for mga5 (if necessary, haven't checked yet if it's vulnerable). No mingw-SDL2 for mga5 to patch.
Version: Cauldron => 6Whiteboard: MGA6TOO, MGA5TOO => MGA5TOO
Built so far: libsdl2.0_0-2.0.5-2.1.mga6 libsdl2.0-devel-2.0.5-2.1.mga6 libsdl2.0-static-devel-2.0.5-2.1.mga6 sdl2-docs-2.0.5-2.1.mga6 mingw32-SDL2-2.0.5-1.mga6 mingw32-SDL2-static-2.0.5-1.mga6 mingw64-SDL2-2.0.5-1.mga6 mingw64-SDL2-static-2.0.5-1.mga6 from SRPMS: sdl2-2.0.5-2.1.mga6.src.rpm mingw-SDL2-2.0.5-1.mga6.src.rpm
Is the SDL library named libSDL-2.0.so.0 or something like that? If so, shouldn't the library package name have SDL capitalized even if the SRPM name is lower case?
(In reply to David Walser from comment #4) > Is the SDL library named libSDL-2.0.so.0 or something like that? If so, > shouldn't the library package name have SDL capitalized even if the SRPM > name is lower case? No, our policy is to always use lowercase regardless of the actual lib name. We have many lib[A-Z]+.so.%{major} libs in lib[a-z]+%{major} packages. SDL12 was just a bad example, sdl2 was better packaged.
I finally took the time to rediff the patch for SDL 2.0.3 on mga5. As mentioned above, there is no mingw-SDL2 on Mageia 5 so nothing to patch. Advisory: ========= Updated SDL2 packages fix security vulnerability Yves Younan of Cisco Talos discovered an exploitable integer overflow vulnerability when creating a new RGB Surface in SDL 2.0.x before version 2.0.7. A specially crafted file can cause an integer overflow resulting in too little memory being allocated which can lead to a buffer overflow and potential code execution. An attacker can provide a specially crafted image file to trigger this vulnerability (CVE-2017-2888). References: - https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0395 - http://hg.libsdl.org/SDL/rev/7e0f1498ddb5 - http://hg.libsdl.org/SDL/rev/81a4950907a0 RPMs in core/updates_testing: ============================= - mga5: libsdl2.0_0-2.0.3-4.1.mga5 libsdl2.0-devel-2.0.3-4.1.mga5 libsdl2.0-static-devel-2.0.3-4.1.mga5 sdl2-docs-2.0.3-4.1.mga5 - mga6: libsdl2.0_0-2.0.5-2.1.mga6 libsdl2.0-devel-2.0.5-2.1.mga6 libsdl2.0-static-devel-2.0.5-2.1.mga6 sdl2-docs-2.0.5-2.1.mga6 mingw32-SDL2-2.0.5-1.mga6 mingw32-SDL2-static-2.0.5-1.mga6 mingw64-SDL2-2.0.5-1.mga6 mingw64-SDL2-static-2.0.5-1.mga6 SRPMs in core/updates_testing: ============================== - mga5: sdl2-2.0.3-4.1.mga5 - mga6: sdl2-2.0.5-2.1.mga6 mingw-SDL2-2.0.5-1.mga6 Testing procedure: ================== No PoC in the original disclosure, so I propose to just test SDL2 applications to ensure that no obvious regression (doesn't start, crashes easily, etc.) occurred. It's likely best tested together with SDL2_image from bug 21881, as most applications use both. $ urpmf --requires :.*sdl2 --synthesis /tmp/synthesis.hdlist.cz | sort 0ad:pkgconfig(sdl2) 7kaa:pkgconfig(sdl2) andy-super-great-park:pkgconfig(sdl2) audaspace:pkgconfig(sdl2) bear:pkgconfig(sdl2) bitfighter:pkgconfig(sdl2) blender:pkgconfig(sdl2) blobby:pkgconfig(sdl2) blobwars:pkgconfig(sdl2) caveexpress:pkgconfig(sdl2) cdogs-sdl:pkgconfig(sdl2) chromium-bsu:pkgconfig(sdl2) colobot:pkgconfig(sdl2) commandergenius:pkgconfig(sdl2) corsixth:pkgconfig(sdl2) crawl:pkgconfig(sdl2) digger:pkgconfig(sdl2) dumb:pkgconfig(sdl2) easyrpg-player:pkgconfig(sdl2) endless-sky:pkgconfig(sdl2) ffmpeg:pkgconfig(sdl2) fifechan:pkgconfig(sdl2) fife:pkgconfig(sdl2) fizmo:pkgconfig(sdl2) freeorion:pkgconfig(sdl2) fs-uae:pkgconfig(sdl2) gambas3:pkgconfig(sdl2) gemrb:pkgconfig(sdl2) goatattack:pkgconfig(sdl2) gource:pkgconfig(sdl2) guvcview:pkgconfig(sdl2)[>= 2.0] hatari:pkgconfig(sdl2) ioquake3:pkgconfig(sdl2) jumpnbump:pkgconfig(sdl2) keeperrl:pkgconfig(sdl2) kodi:sdl2-devel libtcod:pkgconfig(sdl2) lightspark:pkgconfig(sdl2) love:pkgconfig(sdl2) lugaru:pkgconfig(sdl2) mame:sdl2_ttf-devel megaglest:pkgconfig(sdl2) meson:pkgconfig(sdl2) mgba:pkgconfig(sdl2) movit:pkgconfig(sdl2) mpv:pkgconfig(sdl2) naev:pkgconfig(sdl2) neverball:sdl2_image-devel neverball:sdl2_mixer-devel neverball:sdl2_ttf-devel noteye:pkgconfig(sdl2) numptyphysics:pkgconfig(sdl2) openal:pkgconfig(sdl2) openmw:pkgconfig(sdl2) openscenegraph:pkgconfig(sdl2) performous:pkgconfig(sdl2) pioneerspacesim:pkgconfig(sdl2) plee-the-bear:pkgconfig(sdl2) qtgamepad5:pkgconfig(sdl2) redeclipse:pkgconfig(sdl2) rocksndiamonds:pkgconfig(sdl2) sdl2_gfx:pkgconfig(sdl2) sdl2_image:pkgconfig(sdl2) sdl2_mixer:pkgconfig(sdl2) sdl2_net:pkgconfig(sdl2) sdl2_ttf:pkgconfig(sdl2) solarus:pkgconfig(sdl2) speed-dreams:pkgconfig(sdl2) spring:pkgconfig(sdl2) starfighter:pkgconfig(sdl2) stella:pkgconfig(sdl2) stuntrally:pkgconfig(sdl2) supertux:pkgconfig(sdl2) t-engine4:pkgconfig(sdl2) trigger-rally:pkgconfig(sdl2) ufoai:pkgconfig(sdl2) vcmi:pkgconfig(sdl2) vdrift:pkgconfig(sdl2) warzone2100:pkgconfig(sdl2) xonotic:pkgconfig(sdl2) yamagi-quake2:pkgconfig(sdl2)
Whiteboard: MGA5TOO => MGA5TOO has_procedureAssignee: rverschelde => qa-bugs
MGA5-32 on Asus A6000VM Xfce No installation issues. Tried to find some usage for it, avoiding big games # urpmf --requires :.*sdl2 libsdl2_ttf-devel:libsdl2_ttf2.0_0[== 2.0.12-3.mga5] libsdl2_ttf-devel:pkgconfig(sdl2)[>= 2.0.0] libsdl2_net-devel:libsdl2_net2.0_0[== 2.0.0-4.mga5] libsdl2_net-devel:pkgconfig(sdl2)[>= 2.0.0] sdl2_mixer-player:libsdl2_mixer2.0_0[== 2.0.0-4.mga5] libsdl2_mixer-devel:libsdl2_mixer2.0_0[== 2.0.0-4.mga5] libsdl2_mixer-devel:pkgconfig(sdl2) libsdl2_mixer-devel:pkgconfig(sdl2)[>= 2.0.0] libsdl2_image-devel:libsdl2_image2.0_0[== 2.0.0-4.mga5] libsdl2_image-devel:pkgconfig(sdl2) libsdl2_image-devel:pkgconfig(sdl2)[>= 2.0.0] libsdl2.0-devel:libsdl2.0_0[== 2.0.3-4.mga5] libsdl2_gfx-devel:libsdl2_gfx1.0_0[== 1.0.1-1.mga5] libsdl2_gfx-devel:pkgconfig(sdl2)[>= 2.0.0] openra:libsdl2.0_0 libsdl2.0-devel:libsdl2.0_0[== 2.0.3-4.1.mga5] libsdl2_image-devel:libsdl2_image2.0_0[== 2.0.0-4.1.mga5] libsdl2_image-devel:pkgconfig(sdl2) libsdl2_image-devel:pkgconfig(sdl2)[>= 2.0.0] m64py:libsdl2.0_0 Decided on the last one m64py, a front end to a Nintendo64 emulator. Installed it without problems. Run with $ strace -o sdl.txt m64py and ruffled around in its settings as I have to ROM image available. Found in trance open("/usr/lib/libSDL-1.2.so.0.11.4", O_RDONLY|O_CLOEXEC) = 22 and some more stat64 and lstat6 refering to it. So seems OK.
Whiteboard: MGA5TOO has_procedure => MGA5TOO has_procedure MGA5-32-OKCC: (none) => herman.viaene
mga6::x86_64 Installed and updated lib64sdl2 and mingw64-SDL2 and the corresponding image libraries for bug #21881. On mga6::x86_64 Herman's search command turns up gambas and Mingw stuff. Quoting wikipedia, gambas is an object-oriented dialect of BASIC. Installed gambas - the whole package contains 31 RPMs some of which are related to SDL2. Launched the Gambas3 IDE from the menus: Applications -> Development -> Development Environments The IDE gui comes up fullscreen and provides links to download examples. If you agree to download there will probably be messages about needing graphical components, libraries presumably, referencing qt, gtk3 and others. The source code is installed in the gambas3 hierarchy in the user's directory, starting at .local/share/gambas3. I downloaded three, a barcode writer, chart generator and a system tray progress meter. An excerpt from the full directory listing: ~/.local/share/gambas3/src/cogier/BarcodeCreator/.src/FMain.class ~/.local/share/gambas3/src/cogier/BarcodeCreator/.src/FMain.form ~/.local/share/gambas3/src/cogier/ChartExample/.action ~/.local/share/gambas3/src/cogier/ChartExample/.directory It is certainly not practical to take this any further unless the user is already familiar with it but a quick tour of the IDE would suggest that everything is working. This is just one way of ensuring that the SDL2 update is OK. The library components are installed in the /usr/lib64/gambas3 tree and look complete but I cannot determine if the missing download components, like gb.gtk3 are actually missing or have a different name when installed. $ du -hs /usr/lib64/gambas3 8.7M /usr/lib64/gambas3 Followed Herman's lead for m64py. It launches but there is little we can do with it. sdl2show works fine. Point it at an image directory and click from image to image or specify a path to any file of type in the set {JPEG,GIF,PNG,TIFF,XPM,BMP,ICO,PPM}. Individual files can be saved in PNG format and maybe others. Leaving this open until I have some information about Mingw.
CC: (none) => tarazed25
Notes on Mingw What it is, I think: a way of emulating GNU applications on Windows. Cross-compiling can be effected on Linux and the executables should be valid for wine, maybe. See this link: http://www.jonshouse.co.uk/linuxmingw.cgi This talks about running gcc.exe but it is not clear how you get hold of it. It appears that some MinGW components have to be installed somewhere... You can find man entries for mingw utilities using $ apropos mingw i686-w64-mingw32-addr2line (1) - convert addresses into file names and line n... i686-w64-mingw32-ar (1) - create, modify, and extract from archives i686-w64-mingw32-as (1) - the portable GNU assembler. i686-w64-mingw32-c++filt (1) - Demangle C++ and Java symbols. i686-w64-mingw32-dlltool (1) - Create files needed to build and use DLLs. .................... $ man i686-w64-mingw32-addr2line ADDR2LINE(1) GNU Development Tools ADDR2LINE(1) NAME addr2line - convert addresses into file names and line numbers. SYNOPSIS addr2line [-a|--addresses] .................................... Searching the web turns up miggw64-runtime. $ sudo urpmi mingw64-runtime Package mingw64-crt-5.0-0.1.rc2.1.mga6.noarch is already installed $ sudo urpmi mingw64-gcc Package mingw64-gcc-6.1.0-1.mga6.x86_64 is already installed $ sudo urpmi mingw-w64-tools installing mingw-w64-tools-3.1.999-0.8.trunk.git430863.20140530.mga6.x86_64.rpm Fedora has a tutorial! http://fedoraproject.org/wiki/MinGW/Tutorial According to that a cross-compilation can be effected using x86_64-w64-mingw32-gcc, not something a user could guess. $ locate x86_64-w64-mingw32-gcc /usr/bin/x86_64-w64-mingw32-gcc /usr/bin/x86_64-w64-mingw32-gcc-6.1.0 /usr/bin/x86_64-w64-mingw32-gcc-ar /usr/bin/x86_64-w64-mingw32-gcc-nm /usr/bin/x86_64-w64-mingw32-gcc-ranlib /usr/share/man/man1/x86_64-w64-mingw32-gcc.1.gz Had a go at cross-compiling without any real clue. $ x86_64-w64-mingw32-gcc -o compilertest.exe compilertest.c compilertest.c:3:1: warning: return type defaults to 'int' [-Wimplicit-int] main() ^~~~ $ file compilertest.exe compilertest.exe: PE32+ executable (console) x86-64, for MS Windows $ wine ./compilertest.exe err:process:create_process L"C:\\compilertest.exe" not supported on this installation (x86_64 binary) So, no progress. Some problem regarding architectures maybe? Anyway it is time to drop this. It has taken a ridiculous amount of time just to get this far. Looks like a lifetime project.
Addendum to comment 9. Ran the cross compilation under strace and could find no sign of interaction with any sdl2 components, so all that was a waste of time anyway. :-(
Just make sure that mingw* packages install/ upgrade fine, and that will suffice.
Re comment 11. They do, so this gets a 64-bit OK.
Whiteboard: MGA5TOO has_procedure MGA5-32-OK => MGA5TOO has_procedure MGA5-32-OK MGA6-64-OK
Keywords: (none) => advisory
MGA6-32 on Asus A6000VM MATE No installation issues Used as per Comment 7 m644py, runs OK
Whiteboard: MGA5TOO has_procedure MGA5-32-OK MGA6-64-OK => MGA5TOO has_procedure MGA5-32-OK MGA6-64-OK MGA6-32-OK
Keywords: (none) => validated_updateCC: (none) => lewyssmith, sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2017-0398.html
Status: NEW => RESOLVEDResolution: (none) => FIXED