Project

General

Profile

Actions

Bug #4005

closed

segfault with segmented HTTP header

Added by mat Sch almost 9 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
04/24/2015
Due date:
% Done:

0%

Estimated time:

Description

My application is experiencing an infrequent segfault inside of wt using the latest code pulled from git on 4/21/2015 as well as the released 3.3.4. I'm using the whttp connector with websockets enabled. I've run the application under valgrind and it's fine until it gets to the segfault.

The crash occurs in RequestParser.C ::validate method. Specifically it's crashing in strtoll. The value passed into strtoll is null.

My analysis is this is happening because the server receives the "Content-Length" message over two reads. The result is you have one buffer_string struct with "Content" and the other with "-Length".

The crash comes because getHeader(const char *) uses boost:iequal method and that returns true after it successfully compares the first 7 chars. This is wrong. The result is it ends up in the block of code where it thinks it has a valid content length header, but it does not. it subsequently tries to read null when examining the value. I believe getHeader should return false here or a check should be added after getHeader. However, I'm not sure if the buffer_string's will be concatenated to reconstruct a valid http content-length header.

The header that causes the crash is below. Note that the value is null. the data is valid and points to the rest of the content-length header.

(gdb) p (*h)

$17 = {name = {data = 0xa527e71 "Content", len = 7, next = 0xb2e37b54}, value = {data = 0x0, len = 0, next = 0x0}}

(gdb) p (*(h->name.next))

$22 = {data = 0xb2e4fc60 "-Length", len = 9, next = 0x0}

p (*(h->name.next.data))

$27 = 45 '-'

Other notes is there's a lot of traffic going on when this happens so it's hard to pin down client version that's causing the crash. I thought it was just isolated to fireforx requests with websockets but the request has the following.

webSocketVersion = --1

The avg number of requests before a crash is about 800,000 http requests. Takes about 12 hours to get that many.

Thanks for your assistance

Actions #1

Updated by Koen Deforche almost 9 years ago

  • Status changed from New to Resolved
  • Assignee set to Koen Deforche
Actions #2

Updated by Koen Deforche over 8 years ago

  • Status changed from Resolved to Closed
Actions #3

Updated by Koen Deforche over 8 years ago

  • Target version set to 3.3.5
Actions

Also available in: Atom PDF