Closed PromptFuzz closed 7 months ago
Yes, the argument of crc32_combine_gen64()
is the length of a sequence of bytes, which must, of course, be non-negative. Though it is obvious, I will add a note to that effect in zlib.h.
Thank you for your response; I concur with your viewpoint.
Regarding the issue at hand, my confusion stems from the usage of the z_off64_t
type. This type is employed in both the gzoffset64()
and crc32_combine_gen64()
functions. As users of the library, we may not possess the same familiarity with the implementation of crc32_combine_gen64()
as you do. Consequently, users might inadvertently write problematic code patterns such as crc32_combine_gen64(gzoffset64(file))
, unaware of the potential negative consequences.
Thus, I believe it is necessary to mitigate the potential negative impact by providing appropriate documentation or safeguards within the library.
Anyone who writes crc32_combine_gen64(gzoffset64(file))
or for that matter crc32_combine_gen(gzoffset(file))
is implicitly ignoring a possible error indication in the return value of gzoffset()
, which is a no-no. Errors must always be checked for.
Dear Team, I found that the zlib API
crc32_combine_gen64
contains an infinite loop issue.See the PoC program below, I pass an empty mode of
gzopen()
and let it return a NULL. Thengzoffset64(NULL)
will return a value of 0xffffffffffffffff. If the argument passed tocrc32_combine_gen64()
is 0xffffffffffffffff, it will trap in an infinite loop.PoC program: