deflate.c appears to be doing compression. inflate.c[1] is what does decompression.

Are you saying you can modify your gzip compression code locally to generate a malformed gzip file? That wouldn't be exploiting deflate.c , that would be exploiting the receiver's decompression code, which might be inflate.c or some other implementation of gzip decompression, which might be in some other language. The language used by the compression code doesn't seem relevant to me, rather it's the language used by the decompression code that might have vulnerabilities that can be exploited. If you have a compressed gzip file that expands to more than 1032:1, the file itself is a proof of concept of the vulnerability; it doesn't matter whether the file was generated by C, Rust, Python, or in a hex editor by hand.

If you've found something in gzip code that causes it to use significantly more memory or disk space than it should (either during compression or decompression), I think that's a denial or service vulnerability and should be reported to gzip.

[1] https://git.savannah.gnu.org/cgit/gzip.git/tree/inflate.c