Integer truncation error in deflate_buckets.c

[GoogleCodeExporter]

What steps will reproduce the problem?
I was trying to fetch an enormous revision which added many large files from a 
private svn repository using git-svn.

What is the expected output? What do you see instead?
A decompression failed error is produced unnecessarily, preventing git-svn from 
fetching that revision.

What version of the product are you using? On what operating system?
I was using serf 1.3.7 which I compiled from source on Fedora 20, x86_64. I 
have also reproduced this with the Fedora packaged 1.3.4 version.

Please provide any additional information below.
In deflate_buckets.c, serf_deflate_read contains the following code:
            compLen = getLong((unsigned char*)ctx->hdr_buffer + 4);
            if (ctx->zstream.total_out != compLen) {
                serf__log(LOGLVL_ERROR, LOGCOMP_COMPR, __FILE__, ctx->config,
                          "Incorrect length. Expected: %ld, Actual:%ld\n",
                          compLen, ctx->zstream.total_out);
                return SERF_ERROR_DECOMPRESSION_FAILED;
            }
The getLong function only sets 32 bits of the returned value (unsigned long is 
64 bits long on x86_64 Linux). In my case, ctx->zstream.total_out was 
7327732726, and compLen was 3032765430, which is 2^32 less than desired, so 
SERF_ERROR_DECOMPRESSION_FAILED is returned. If I jump over the return 
statement in a debugger, everything seemed to continue as expected.

Original issue reported on code.google.com by jl...@feralinteractive.com on 19 Aug 2014 at 2:17

[GoogleCodeExporter]

Thanks for the report, r2419 fixes this issue.

The problem is not so much that serf is truncating the length. The problem is 
that the gzip trailer sent by the http server only contains the expected length 
module 2^32, so when we compare it we have to use the actual value module 2^32.

Original comment by lieven.govaerts@gmail.com on 20 Aug 2014 at 4:13

• Changed state: Fixed