3 ms·
It was not caused by a bug in Ragel, though.
by rhencke 9y ago
It was not caused by a bug in Ragel, though.
- wuch 9y agoTo provide a little bit more context, here is detailed description of this bug [0]. Curiously, they suggest that problem could be avoided by changing the check for EOF to ">=". This is not true at all in case of C, at least as far as language semantics is concerned. When pointer goes two past the end of array you are already in undefined behaviour land. [0] https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/ https://blog.cloudflare.com/incident-report-on-memory-leak-c...
- striking 9y agoMore specifically: > The Ragel code we wrote contained a bug that caused the pointer to jump over the end of the buffer and past the ability of an equality check to spot the buffer overrun.
- ioquatix 9y agoI think it's valid in C/C++ to go 1 past the end of an array: https://stackoverflow.com/questions/988158/take-the-address-of-a-one-past-the-end-array-element-via-subscript-legal-by-the https://stackoverflow.com/questions/988158/take-the-address-...
- staticassertion 9y agoThis is always going to lead to the same place - whether it's the developer's fault or the tool's. The author of this post wants uncompromising safety, ragel does not allow for that - programmer error can introduce memory unsafety. They even explicitly call out Cloudbleed.
- ioquatix 9y agoA simple `assert(p<pe);` in a debug build would have caught the issue. I think you could argue that ragel should include something like this by default.