A heap overflow in the jit-wasm which could lead to code execution. In function WAST::lex(), when adding the pointer nextToken, there is no boundary check.
Description:
it seems that the bug happens at the WAST::lex
const Uptr numLineStarts = nextLineStart - lineStarts;
const Uptr numTokens = nextToken - tokens;
lineStarts = (U32*)realloc(lineStarts,sizeof(U32) * numLineStarts);
tokens = (Token*)realloc(tokens,sizeof(Token) * numTokens);
// Create the LineInfo object that encapsulates the line start information.
outLineInfo = new LineInfo {lineStarts,U32(numLineStarts)};
because oldsize >= av->system_mem,it will trigger the error "realloc(): invalid old size"
but why it will trigger this error, lets find when the lineStarts is malloced.
I wrote a gdb script to test it, and found that at
nextToken is not limited, and when tring to ++nextToken, it can assess to the chunk next to it which is lineStarts. it will overwrite the metadata of lineStarts, so we will have a heap overflow here...
The text was updated successfully, but these errors were encountered:
This bug is already reported at hackerone and has been solved
It's just public here.
Vendor:eosio
Affected product:libraries/wasm-jit
Product Version: 4.1
Git commit hash:29799eae7bb919e480981e6abf110dfa75198f8d
Summary:
A heap overflow in the jit-wasm which could lead to code execution. In function WAST::lex(), when adding the pointer nextToken, there is no boundary check.
Description:
it seems that the bug happens at the WAST::lex
when realloc the linsStarts
because oldsize >= av->system_mem,it will trigger the error "realloc(): invalid old size"
but why it will trigger this error, lets find when the lineStarts is malloced.
I wrote a gdb script to test it, and found that at
nextToken is not limited, and when tring to ++nextToken, it can assess to the chunk next to it which is lineStarts. it will overwrite the metadata of lineStarts, so we will have a heap overflow here...
The text was updated successfully, but these errors were encountered: