Serf crashes on incorrect response from server.

[GoogleCodeExporter]

If server respond with slightly incorrect output without HTTT Reason in 
Status-Line serf crashes on parsing it and trying of allocate 2^63 (or 2^31) 
bytes of memory.

For example respond like this:
"HTTP/1.1 302
Location: ...
....
"

will lead to crash in parse_status_line in serf/instaweb_respond_buckets. 

Code in which it crashes is:

    /* Skip leading spaces for the reason string. */
    if (apr_isspace(*reason)) {
        reason++;
    }

    /* Copy the reason value out of the line buffer. */
    ctx->sl.reason = serf_bstrmemdup(allocator, reason,
                                     ctx->linebuf.used
                                     - (reason - ctx->linebuf.line));

In example above it gives me next values:

(gdb) p ctx->linebuf.used
$15 = 12
(gdb) p reason
$16 = 0x7fffdc0d3a35 "Server: nginx\r\nDate: Tue, 24 Jun 2014 06:55:55 
GMT\r\nContent-Type: image/gif\r\nContent-Length: 43\r\nLast-Modified: Mon, 28 
Sep 1970 06:00:00 GMT\r\nConnection: keep-alive\r\nKeep-Alive: 
timeout=70\r\nExpires: "...
(gdb) p reason - ctx->linebuf.line
$17 = 13

Which leads to allocating of -1 (2^63) bytes serf_bstrmemdump.

Original issue reported on code.google.com by ba...@bacek.com on 24 Jun 2014 at 7:14

[GoogleCodeExporter]

Hi.

I suppose you're encountering this crash while using mod_pagespeed? It includes 
a modified older version of serf, you're probably better of reporting to the 
mod_pagespeed devs.

This being said, I can't reproduce this issue with serf trunk. I don't see how 
it's possible to get in the situation you see in gdb with current code.
What are the characters right after the 302 code? Is that \r\n?

Can you reproduce this with serf 1.3.6 or serf trunk (e.g. with serf_get) ?

Lieven

Original comment by lieven.govaerts@gmail.com on 24 Jun 2014 at 11:06

[GoogleCodeExporter]

Hello.

Yes, it is in mod_pagespeed. And I can't reproduce it with serf_get.

Thank you. I'll report this bug to mod_pagespeed dev team.

Vasily

Original comment by ba...@bacek.com on 24 Jun 2014 at 11:34

[GoogleCodeExporter]

Thanks for the feedback, closing this issue as "can't reproduce".

Original comment by lieven.govaerts@gmail.com on 28 Jun 2014 at 9:22

• Changed state: Invalid