Changes

* 2^32 characters long string(still affects latest spider version as of system-version v10.3): this is similar to the vulnerability fixed [http://git.chromium.org/gitweb/?p=external/Webkit.git;a=commitdiff;h=ec471f16fbd1f879cb631f9b022fd16acd75f4d4 here], concat-large-strings-crash2.html triggers a crash which is about the same as the one triggered by a 2^32 string. Most of the time this vulnerability will cause a memory page permissions fault, since the WebKit code attempts to copy the string text data to the output buffer located in read-only [[CRO0|CRO]] heap memory. The only difference between a crash triggered by a 2^32 string and the concat-large-strings-crash2.html crash is at the former copies the string data using the original string length(like 1 text character for "x", 4 for "xxxx") while the latter attempts to copy >12MB. In some ''very'' rare cases a thread separate from the string data-copy thread will crash, this might be exploitable. However, this is mostly useless since it rarely crashes this way.

* 2^32 characters long string(still affects latest spider version as of system-version v10.3): this is similar to the vulnerability fixed [http://git.chromium.org/gitweb/?p=external/Webkit.git;a=commitdiff;h=ec471f16fbd1f879cb631f9b022fd16acd75f4d4 here], concat-large-strings-crash2.html triggers a crash which is about the same as the one triggered by a 2^32 string. Most of the time this vulnerability will cause a memory page permissions fault, since the WebKit code attempts to copy the string text data to the output buffer located in read-only [[CRO0|CRO]] heap memory. The only difference between a crash triggered by a 2^32 string and the concat-large-strings-crash2.html crash is at the former copies the string data using the original string length(like 1 text character for "x", 4 for "xxxx") while the latter attempts to copy >12MB. In some ''very'' rare cases a thread separate from the string data-copy thread will crash, this might be exploitable. However, this is mostly useless since it rarely crashes this way.

* Trying to directly load a page via the browser "URL" option with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] setup, causes a crash to trigger in oss.cro due to an use-after-free being caught with webkitdebug. This is presumably some sort of realloc() issue in the libcurl version used by the <={v10.2-v10.3} browser. This happens with *every* *single* *page* one tries to load via the "URL" option, but not when loading links on the current page, hence this is probably useless.

* Trying to directly load a page via the browser "URL" option with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] setup, causes a crash to trigger in oss.cro due to an use-after-free being caught with webkitdebug. This is presumably some sort of realloc() issue in the libcurl version used by the <={v10.2-v10.3} browser. This happens with *every* *single* *page* one tries to load via the "URL" option, but not when loading links on the current page, hence this is probably useless. A different use-after-free with realloc triggers with loading any page at all regardless of method too(libcurl probably).