Control: reassign 948598 src:mingw-w64 7.0.0-2 Control: forcemerge 897196 948598
On 2020-01-10 23:18:09 +0100, Stephen Kitt wrote: > Control: merge -1 897196 > > Hi, > > On Fri, 10 Jan 2020 22:43:27 +0100, Bernhard Übelacker > <bernha...@mailbox.org> wrote: > > In the regular case the resulting exe seems to link > > to msvcrt.dll!_vsnprintf: > > > > $ i686-w64-mingw32-objdump --private-headers test.c.exe > > DLL Name: msvcrt.dll > > vma: Hint/Ord Member-Name Bound-To > > 63e8 766 _vsnprintf > > > > Under wine we then get to that location: > > #0 0x7eb514d6 in MSVCRT_vsnprintf (str=0x65fe64 "", len=3, > > format=0x40400b "abcdef", valist=0x65fe5c "+\026@") > > at /home/benutzer/wine/wine-git/wine-git/dlls/msvcrt/wcs.c:686 > > > > The resulting executables are showing the same output > > in wine and windows. > > Yes; this is a bug in MSVCRT. > > > In the posix case it seems the snprintf implementation is > > not taken from any dll, instead it is contained inside > > the executable, therefore supplied by the compiler? > > > > Microsoft states [1], that they switched in VS2015 snprintf > > to be C99 compliant, wouldn't therefore snprintf in msvcrt.dll > > not compliant? Yes, it seems to be the remaining case where snprintf is not C99 compliant. FYI, in the past, we had to build GMP and GNU MPFR with -D__USE_MINGW_ANSI_STDIO (or equivalent). Now, this is working correctly, except in the particular case of GMP 6.1.2 built with assertions enabled. Internally, GMP 6.1.2 assumes that a return value of -1 means that the size was too small (in the past, this was due to the behavior of some old glibc version). With assertions enabled, there is another check that was working with glibc, but fails with MinGW, and worse, this triggers a buffer overflow as the assertion uses strlen while vsnprintf under MinGW does not return a string (no terminating \0). > > Is this issue in the end that mingw should link to > > newer c-library by default? > > I’m not sure what the exact fix should be, apart from building with -posix > or #define __USE_MINGW_ANSI_STDIO 1. This is filed upstream as > https://sourceforge.net/p/mingw-w64/bugs/709/ (and CVE-2018-1000101), and > apparently MSVCRT’s vsnprintf does the right thing now, but I haven’t had the > time to figure out how to use that correctly yet. Indeed, concerning the security issue, GMP 6.1.2 is such an example where one can get a buffer overflow. Note that the GMP development code has changed due to another issue I reported two years ago. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
