Added Showcase entries for JerryScript. #80
Conversation
…ted as DoS and caused a crash in the normal builds too.
This should speed up network synchronization in many cases.
This makes the fuzzer much more responsive as minimization can take multiple seconds up to (probably) a few minutes and, if that happens on the main fuzzer queue, the fuzzer is unresponsive during that time.
README.md
Outdated
| @@ -182,6 +182,13 @@ The following is a list of some of the bugs found with the help of Fuzzilli. Onl | |||
| * [Issue 2323](https://github.com/svaarala/duktape/pull/2323): Unstable valstack pointer in putprop | |||
| * [Issue 2320](https://github.com/svaarala/duktape/pull/2320): Memcmp pointer overflow in string builtin | |||
|
|
|||
| #### [JerryScript](https://github.com/jerryscript-project/jerryscript) | |||
|
|
|||
| - [CVE-2020-13622](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13622): DoS via property key query for Proxy objects | |||
There was a problem hiding this comment.
Here and the one below, are you certain these are just DoS and cannot be exploited for e.g RCE? E.g. the stack overflow might be exploitable if it can be collided with another memory region. Also the assertion message here sounds like it could cause memory corruption in release builds (Afaict the JERRY_ASSERT is only active in debug builds and ignored in release builds)? If you are unsure, maybe you can just change the description to something that doesn't include the (worst-case) bug impact, like for example "Unexpected non-string value in ecma_get_string_from_value" and "Stack overflow via property key for Proxy objects"?
|
Cool stuff! I'm curious, what about some of the other issues you reported that also appear to trigger memory corruption (e.g. jerryscript-project/jerryscript#3837 or maybe jerryscript-project/jerryscript#3784)? |
This seems to roughly speed up encoding + decoding of Programs by a factor of 8, while reducing the size of the encoded data roughly by a factor of 4.
Generators and async functions are now supported.
It has a decent API and a new client in Sources/REPRLRun, useful for testing REPRL support in a target. Also, libreprl can now capture the target's stdout and stderr with low overhead if requested.
|
Ping @nszetei :) |
Thank you for reminding and keeping this pull request open, I wanted to dedicate more time on this to be sure and I'll finalize the list by the end of this week. |
|
Awesome, thanks! :) |
…ted as DoS and caused a crash in the normal builds too.
|
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
All of the entries were reported as DoS and caused a crash in the normal builds too.