From ${URL} : #include <fnmatch.h> #include <string.h> int main(int argc, const char* argv[]) { const char text[] = {44, 92, 91, 44, 91, 46, 0}; const char p[] = {91, 44, 91, 46, 0}; const char *Pat = strdup(p); fnmatch(Pat, text, 0); } gcc -g fn2.c && valgrind ./a.out # 2.19 ==32342== Invalid read of size 1 ==32342== at 0x4EFEF92: internal_fnmatch (fnmatch_loop.c:965) ==32342== by 0x4EFFF71: fnmatch@@GLIBC_2.2.5 (fnmatch.c:458) ==32342== by 0x400663: main (fn2.c:7) ==32342== Address 0x51fc045 is 0 bytes after a block of size 5 alloc'd ==32342== at 0x4C2ABBD: malloc (vg_replace_malloc.c:296) ==32342== by 0x4EBF3C9: strdup (strdup.c:42) ==32342== by 0x400647: main (fn2.c:6) Reproduced on 2.19 and on fresh trunk; initially found with an experimental AddressSanitizer build of glibc and a coverage guided fuzzer. # trunk ==32737==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000eff5 at pc 0x7f0bc10c9588 bp 0x7fff4676fef0 sp 0x7fff4676fee8 READ of size 1 at 0x60200000eff5 thread T0 #0 0x7f0bc10c9587 in internal_fnmatch posix/./fnmatch_loop.c:951:8 #1 0x7f0bc10b3014 in __GI_fnmatch posix/fnmatch.c:458:10 #2 0x4c1e3f in main 0x60200000eff5 is located 0 bytes to the right of 5-byte region [0x60200000eff0,0x60200000eff5) allocated by thread T0 here: #0 0x48d23c in __interceptor_strdup #1 0x4c1dfe in main See also https://sourceware.org/bugzilla/show_bug.cgi?id=17062 -- a different bug somewhere similar. @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
https://sourceware.org/bugzilla/show_bug.cgi?id=18032 Andreas Schwab 2015-02-26 15:14:58 UTC Fixed in 2.22.
this has been fixed for glibc 2.22 and 2.21.1, and i've backported it to our glibc 2.21-r1 ebuild. but that's just now hitting ~arch so it'll be a little while before we can stabilize.
This issue was resolved and addressed in GLSA 201602-02 at https://security.gentoo.org/glsa/201602-02 by GLSA coordinator Tobias Heinlein (keytoaster).
