text: 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 -- 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.
  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
  by GLSA coordinator Tobias Heinlein (keytoaster).