heap-use-after-free in rpl_glob

[Tim Rühsen]

Hi,

I recently updated wget2 to gnulib commit
a7903da07d3d18c23314aa0815adbb4058fd7cec.

The continuous fuzzer at OSS-Fuzz today reported an issue in rpl_glob.

To reproduce with attached C code (on Debian unstable here, same result
on Ubuntu 16.04.6 docker container with clang 10):

export CC=gcc
export CFLAGS="-O1 -g -fno-omit-frame-pointer -fsanitize=address
-fsanitize-address-use-after-scope"
# ... build gnulib ...
$CC $CFLAGS -I. -Ilib glob_crash2.c -o glob_crash2 lib/.libs/libgnu.a
./glob_crash2

=================================================================
==1671628==ERROR: AddressSanitizer: heap-use-after-free on address
0x604000000013 at pc 0x55fa90a36ecd bp 0x7ffe68412980 sp 0x7ffe68412978
READ of size 44 at 0x604000000013 thread T0
    #0 0x55fa90a36ecc in rpl_glob /home/tim/src/wget2/lib/glob.c:868
    #1 0x55fa90a334eb in main /home/tim/src/wget2/glob_crash2.c:35
    #2 0x7fdafafabbba in __libc_start_main ../csu/libc-start.c:308
    #3 0x55fa90a332f9 in _start (/home/tim/src/wget2/glob_crash2+0x22f9)

0x604000000013 is located 3 bytes inside of 48-byte region
[0x604000000010,0x604000000040)
freed by thread T0 here:
    #0 0x7fdafb24c277 in __interceptor_free
(/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107277)
    #1 0x55fa90a36e31 in rpl_glob /home/tim/src/wget2/lib/glob.c:849
    #2 0x55fa90a334eb in main /home/tim/src/wget2/glob_crash2.c:35
    #3 0x7fdafafabbba in __libc_start_main ../csu/libc-start.c:308

previously allocated by thread T0 here:
    #0 0x7fdafb24c628 in malloc
(/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107628)
    #1 0x55fa90a35311 in rpl_glob /home/tim/src/wget2/lib/glob.c:565
    #2 0x55fa90a334eb in main /home/tim/src/wget2/glob_crash2.c:35
    #3 0x7fdafafabbba in __libc_start_main ../csu/libc-start.c:308

SUMMARY: AddressSanitizer: heap-use-after-free
/home/tim/src/wget2/lib/glob.c:868 in rpl_glob
Shadow bytes around the buggy address:
  0x0c087fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c087fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c087fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c087fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c087fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c087fff8000: fa fa[fd]fd fd fd fd fd fa fa 00 00 00 00 00 01
  0x0c087fff8010: fa fa 00 00 00 00 00 01 fa fa 00 00 00 00 06 fa
  0x0c087fff8020: fa fa 00 00 00 00 06 fa fa fa 00 00 00 00 02 fa
  0x0c087fff8030: fa fa 00 00 00 00 02 fa fa fa 00 00 00 00 00 fa
  0x0c087fff8040: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
  0x0c087fff8050: fa fa 00 00 00 00 00 fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==1671628==ABORTING


Maybe someone who knows glob better than me could have a look. It seems
to be a regression.

Regards, Tim

glob_crash2.c
Description: Text Data

signature.asc
Description: OpenPGP digital signature