Assertion In Pow10.h is triggered in Document::Parse

[dkw72n]

here is the code that triggered the assertion

#include "rapidjson/document.h"
int main()
{
    const char * json = "{\"asd\":[1e-00011111111111]}";
    rapidjson::Document d;
    d.Parse(json);
    return 0;
}

output:

[root@localhost build]# g++ a.cpp && ./a.out
a.out: ../include/rapidjson/internal/pow10.h:46: double rapidjson::internal::Pow10(int): Assertion `n >= 0 && n <= 308' failed.
已放弃

This happened because integer overflowed while parsing the exponent.
In rapidjson/include/rapidjson/reader.h:926

            if (s.Peek() >= '0' && s.Peek() <= '9') {
                exp = s.Take() - '0';
                while (s.Peek() >= '0' && s.Peek() <= '9') {
                    exp = exp * 10 + (s.Take() - '0');  // <-- Probably Overflow Here !!!
                    if (exp > 308 && !expMinus) // exp > 308 should be rare, so it should be checked first.
                        RAPIDJSON_PARSE_ERROR(kParseErrorNumberTooBig, s.Tell());
                }
            }
            else
                RAPIDJSON_PARSE_ERROR(kParseErrorNumberMissExponent, s.Tell());

[miloyip]

This is a bug. It is very important because it reads out-of-bound memory. I have done a quick fix in 93d13ad.

During the fix, I also find that some numbers with different form will generate a parse error:

"1.7976931348623157e+308"   -> kParseErrorNone
"0.017976931348623157e+310" -> kParseErrorNumberTooBig

I have also push a commit to solve this second problem.

Besides, I also notify that there will be still some artifical cases with incorrect kParseErrorNumberTooBig, such as the integer part >= 1.7976931348623157 x 10^307 but the exponent is negative to make the actual value within possible double range. However, I think this false alarm is unimportant.

[dkw72n]

Hi miloyip, thanks for responding so quickly.
I review you commit, and am afraid the bug still exists.
Try this input: 1e-429496728999

[miloyip]

My bad... I forgot exp is signed integer. The new 7708215 should be conservative.

[dkw72n]

Thanks again, I think this time it is really fixed.

I should mention that this bug was initially triggered by a fuzzer called "american fuzzy lop", which is written by a google staff: http://lcamtuf.coredump.cx/afl/