Bug #4005
closedsegfault with segmented HTTP header
0%
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
Updated by Koen Deforche over 9 years ago
- Status changed from New to Resolved
- Assignee set to Koen Deforche
Updated by Koen Deforche about 9 years ago
- Status changed from Resolved to Closed