[zlib] minigzip_fuzzer: compression level encoding bug — only level 6 ever tested

[OwenSanzas]

Summary

projects/zlib/minigzip_fuzzer.c encodes the compression level as a raw integer (0x00–0x09) instead of an ASCII digit ('0'–'9'), so gzopen() always falls back to the default compression level 6. The fuzzer never tests levels 0–5 or 7–9.

Bug

Line 468:

outmode[2] = data[0] % 10;    // BUG: produces 0x00–0x09 (control characters)

The outmode string is passed to gzopen() as the mode parameter (e.g., "wb6"). The third character should be an ASCII digit. However, data[0] % 10 produces raw integer values 0–9 (bytes 0x00–0x09), which are non-printable control characters.

In zlib's gz_open(), the level is parsed as:

while (*plevel) {
    if (*plevel >= '0' && *plevel <= '9') {
        level = *plevel - '0';
        break;
    }
    plevel++;
}

Since 0x00–0x09 don't satisfy >= '0' (0x30), the loop never matches, and gzopen uses Z_DEFAULT_COMPRESSION (level 6) every time.

Additional Issues

Resource leak in file_compress() (line 392): When gzopen() fails, FILE *in is never closed.

Resource leak in file_uncompress() (line 436): When fopen() fails, gzFile in is never closed.

Evidence

Coverage comparison (ASan, 60-second runs):

Metric	Original	Fixed	Change
INITED edges (same seed corpus)	815	866	+6.3% (+51 edges)
Final edges (after 60s)	870	968	+11.3% (+98 edges)

Fix

PR: #15099