**Description**
Function [gf_gz_decompress_payload_ex()](https://github.com/gpac/gpac/blob/205bfe3196764b61b19b63494a2b4708ac774b71/src/utils/base_encoding.c#L252) passes uninitialized buffer `data` to the function `inflate()` (through `d_stream.next_in`)

**Details**
In [box_funcs.c:118](https://github.com/gpac/gpac/blob/205bfe3196764b61b19b63494a2b4708ac774b71/src/isomedia/box_funcs.c#L118) `size` is read from the input. This value is then used to allocate memory ( in [box_funcs.c:198](https://github.com/gpac/gpac/blob/205bfe3196764b61b19b63494a2b4708ac774b71/src/isomedia/box_funcs.c#L198)); the allocated buffer should be initialized by the function `gf_bs_read_data()` in [box_funcs.c:202](https://github.com/gpac/gpac/blob/205bfe3196764b61b19b63494a2b4708ac774b71/src/isomedia/box_funcs.c#L202) but the return value of this function (i.e. the number of read bytes) is not checked. Regardless of how many bytes are read, the whole buffer and the `size` variable are passed to the function `gf_gz_decompress_payload_ex()` in [box_funcs.c:203](https://github.com/gpac/gpac/blob/205bfe3196764b61b19b63494a2b4708ac774b71/src/isomedia/box_funcs.c#L203) which then passes the (uninitialized) buffer to the function `inflate()` in [base_encoding.c:254](https://github.com/gpac/gpac/blob/205bfe3196764b61b19b63494a2b4708ac774b71/src/utils/base_encoding.c#L254).

A possible fix might be to check the return value of the function `gf_bs_read_data()` in [box_funcs.c:202](https://github.com/gpac/gpac/blob/205bfe3196764b61b19b63494a2b4708ac774b71/src/isomedia/box_funcs.c#L202) and either exit with an error or adjust the values accordingly if the expected size does not match the number of read bytes. The testcase provided in the PoC is only 10 bytes long, but triggers an allocation of millions of bytes since the first bytes appear to be interpreted as the size of the payload. The return value of the function `gf_bs_read_data()` with the given input is `0`.

**To Reproduce**
The [attached archive](https://github.com/gpac/gpac/files/15096139/gpac.zip) contains:
- the executable on which we performed our tests (commit hash: 205bfe3)
- the input file to exercise the bug
- the stacktrace when the bug was observed
- the output of Valgrind confirming our finding

At least for this testcase, a memory safety tool is required to expose the bug. To reproduce, run the given binary with the testcase file inside valgrind with a command like `valgrind --track-origins=yes ./fuzz_parse uninit_mem/testcase`.

The binary in the archive is a compiled version of the fuzzing harness you made available for OSS-Fuzz (i.e. `testsuite/oss-fuzzers/fuzz_parse.c`), with a main() function that simply opens a file, reads its content and calls the LLVMFuzzerTestOneInput() function. To compile, we used clang 14 and we ran every test on an ubuntu 22.04 x86-64 machine.

**Impact**
Use-of-uninitialized-memory violations can lead to security issues, but we could not assess the potential impact of this one in depth. We believe the severity (e.g., a local DoS from crash) will depend also on how erratically inflate() may behave on the random data from the uninitialized buffer. Since the testcase we generated does not cause a cash, we followed your policies in `SECURITY.md` and reported it here.

Use of uninitialized memory in gf_gz_decompress_payload_ex()
This is a GitHub Issue
repo:gpac
owner:gpac
Title : Use of uninitialized memory in gf_gz_decompress_payload_ex()
Issue date:

--- start body ---
**Description**
Function [gf_gz_decompress_payload_ex()](https://github.com/gpac/gpac/blob/205bfe3196764b61b19b63494a2b4708ac774b71/src/utils/base_encoding.c#L252) passes uninitialized buffer `data` to the function `inflate()` (through `d_stream.next_in`)

**Details**
In [box_funcs.c:118](https://github.com/gpac/gpac/blob/205bfe3196764b61b19b63494a2b4708ac774b71/src/isomedia/box_funcs.c#L118) `size` is read from the input. This value is then used to allocate memory ( in [box_funcs.c:198](https://github.com/gpac/gpac/blob/205bfe3196764b61b19b63494a2b4708ac774b71/src/isomedia/box_funcs.c#L198)); the allocated buffer should be initialized by the function `gf_bs_read_data()` in [box_funcs.c:202](https://github.com/gpac/gpac/blob/205bfe3196764b61b19b63494a2b4708ac774b71/src/isomedia/box_funcs.c#L202) but the return value of this function (i.e. the number of read bytes) is not checked. Regardless of how many bytes are read, the whole buffer and the `size` variable are passed to the function `gf_gz_decompress_payload_ex()` in [box_funcs.c:203](https://github.com/gpac/gpac/blob/205bfe3196764b61b19b63494a2b4708ac774b71/src/isomedia/box_funcs.c#L203) which then passes the (uninitialized) buffer to the function `inflate()` in [base_encoding.c:254](https://github.com/gpac/gpac/blob/205bfe3196764b61b19b63494a2b4708ac774b71/src/utils/base_encoding.c#L254).

A possible fix might be to check the return value of the function `gf_bs_read_data()` in [box_funcs.c:202](https://github.com/gpac/gpac/blob/205bfe3196764b61b19b63494a2b4708ac774b71/src/isomedia/box_funcs.c#L202) and either exit with an error or adjust the values accordingly if the expected size does not match the number of read bytes. The testcase provided in the PoC is only 10 bytes long, but triggers an allocation of millions of bytes since the first bytes appear to be interpreted as the size of the payload. The return value of the function `gf_bs_read_data()` with the given input is `0`.

**To Reproduce**
The [attached archive](https://github.com/gpac/gpac/files/15096139/gpac.zip) contains:
- the executable on which we performed our tests (commit hash: 205bfe3)
- the input file to exercise the bug
- the stacktrace when the bug was observed
- the output of Valgrind confirming our finding

At least for this testcase, a memory safety tool is required to expose the bug. To reproduce, run the given binary with the testcase file inside valgrind with a command like `valgrind --track-origins=yes ./fuzz_parse uninit_mem/testcase`.

The binary in the archive is a compiled version of the fuzzing harness you made available for OSS-Fuzz (i.e. `testsuite/oss-fuzzers/fuzz_parse.c`), with a main() function that simply opens a file, reads its content and calls the LLVMFuzzerTestOneInput() function. To compile, we used clang 14 and we ran every test on an ubuntu 22.04 x86-64 machine.

**Impact**
Use-of-uninitialized-memory violations can lead to security issues, but we could not assess the potential impact of this one in depth. We believe the severity (e.g., a local DoS from crash) will depend also on how erratically inflate() may behave on the random data from the uninitialized buffer. Since the testcase we generated does not cause a cash, we followed your policies in `SECURITY.md` and reported it here.

--- end body ---
