zlib

BUG OF THE MONTH | Dereferencing of the null pointer

// trees.c
void ZLIB_INTERNAL _tr_stored_block(s, buf, stored_len, last)
    deflate_state *s;
    charf *buf;       /* input block */
    ulg stored_len;   /* length of input block */
    int last;         /* one if this is the last block for a file */
{
    // ....
    zmemcpy(s->pending_buf + s->pending, (Bytef *)buf, stored_len);      
    // ....
}

// deflate.c
local block_state deflate_stored(s, flush)
    deflate_state *s;
    int flush;
{
    ....
    /* Make a dummy stored block in pending to get the header bytes,
     * including any pending bits. This also updates the debugging counts.
     */
    last = flush == Z_FINISH && len == left + s->strm->avail_in ? 1 : 0;
    _tr_stored_block(s, (char *)0, 0L, last);                            
    ....
}

V522 Dereferencing of the null pointer might take place. The null pointer is passed into ‘_tr_stored_block’ function. Inspect the second argument. Check lines: ‘trees.c:873’, ‘deflate.c:1690’.

The null pointer (char*)0 gets into memcpy as the second argument via the _tr_stored_block function. It looks like there is no real problem—zero bytes are copied. But the standard clearly states the opposite. When we call functions like memcpy, pointers must point to valid data, even if the quantity is zero. Otherwise, we have to deal with undefined behavior.

The error has been fixed in the develop-branch, but not in the release version. It’s been 4 years since the project team released updates. Initially, the error was found by sanitizers.

Please click here to see more bugs from this project.