Opened 6 years ago

Last modified 6 years ago

#94 new defect

zzuf doesn't catch *** glibc detected *** messages

Reported by: D. Wagner Owned by: Sam Hocevar
Priority: major Milestone:
Component: core Version: SVN
Keywords: Cc:
Product: zzuf

Description

I'm using zzuf to fuzz a program, and zzuf successfully triggered the program to emit the following message:

*** glibc detected *** ./bin/flags.none/ffmpeg: corrupted double-linked list: 0x00000000026799c0 ***

However, zzuf doesn't seem to hook or detect this error. Instead, after it emits this message, the program sits blocked, doing nothing. Here's a stack backtrace:

(gdb) bt
#0  __lll_lock_wait_private ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97
#1  0x00000035daa7c021 in _L_lock_10398 () from /lib64/libc.so.6
#2  0x00000035daa79ff2 in __libc_malloc (bytes=231304950208) at malloc.c:3657
#3  0x00007f2e59aa228d in malloc (size=231304950208) at libzzuf/lib-mem.c:202
#4  0x00000035daa6fc9c in __libc_message (do_abort=2, 
    fmt=0x35dab5ea78 "*** glibc detected *** %s: %s: 0x%s ***\n")
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:137
#5  0x00000035daa76513 in malloc_printerr (av=0x35dad971c0) at malloc.c:6283
#6  malloc_consolidate (av=0x35dad971c0) at malloc.c:5169
#7  0x00000035daa76cc8 in _int_free (av=0x35dad971c0, p=0x27943a0, have_lock=0)
    at malloc.c:5034
#8  0x000000000095e58c in av_free (arg=0x2660cb8) at libavutil/mem.c:152
#9  av_freep (arg=0x2660cb8) at libavutil/mem.c:159
#10 0x00000000006f4753 in free_duplicate_context (s=0x265e1e0)
    at libavcodec/mpegvideo.c:420
#11 MPV_common_end (s=0x265e1e0) at libavcodec/mpegvideo.c:797
#12 0x0000000000419f7a in MPV_encode_end (avctx=<value optimized out>)
    at libavcodec/mpegvideo_enc.c:775
#13 0x00000000004223e5 in avcodec_close (avctx=0x268d1a0)
    at libavcodec/utils.c:884
#14 0x000000000043a1ee in transcode (output_files=0x26b9b80, 
    nb_output_files=<value optimized out>, input_files=0x2, 
    nb_input_files=1152) at ffmpeg.c:2640
#15 0x000000000043cdc1 in main (argc=<value optimized out>, 
    argv=<value optimized out>) at ffmpeg.c:4378

Suggestion: zzuf should somehow hook the appropriate spot in glibc and detect this situation, and treat it as a successful crash of the program. Perhaps this means hooking malloc_printerr().

Setting the environment variable LIBC_FATAL_STDERR_=1 did not help.

Also, if I don't set the -U command-line option, this blocks the rest of the fuzzing run, because the program sits forever blocked (waiting to acquire a lock?), consuming no CPU time.

I'm using zzuf on Fedora: zzuf-0.13-1.fc13.x86_64

Change History (1)

comment:1 Changed 6 years ago by D. Wagner

Incidentally, should zzuf do some sanity checking of the arguments to its malloc? If it sees a malloc with a humongous argument, should it treat this as a crash?

Note: See TracTickets for help on using tickets.