Brad ArantandClaude Sonnet 5
2cea81c996
HTTPRequest::parse() passed the parsed Content-Length straight into a bounds check and a buffer read with no validation. ZString::asInteger() accumulates digits into a plain 32-bit int with no overflow check, so a request claiming an absurd Content-Length (confirmed live: a classic SSTP vulnerability-scanner probe sending "Content-Length: 18446744073709551615") silently overflowed to -1. That negative value passed the "buffer.getLength() < contentLength" guard for any real buffer size, then got used as a length in ZString(cursor, contentLength) - reinterpreted as an enormous size_t, this read far past the real buffer and corrupted the heap, crashing the process (sometimes immediately, sometimes much later in an unrelated objects destructor) every time this scanner traffic reached it. This single bug was silently crash-looping barant.com (3x in ~30 hours) and the ClockPlanet server (3x over the same window) before systemds auto-restart each time masked the outage - confirmed via live core dump analysis (gdb bt full showing double free or corruption (out) inside MString::~MString, called from HTTPRequest::parse, with contentLength = -1 in the frame). Fixed by rejecting a negative Content-Length immediately, before it is ever used - the same throw-on-malformed-input pattern this function already uses for a bad request line and unsupported Transfer-Encoding. Verified live against the exact attack string on both barant.com and the ClockPlanet server: the connection is now cleanly rejected and the service stays up with no restart. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>