The crash is due to a recently discovered bug in Chrome - and other WebKit browsers(!)* - specifically related to either
%%300 as part of the URL, which internally all end up representing the same symbol: null. You can read more about the bug here.
It's not a bug that affect most links, so you don't generally have to worry about hovering over links.
* Other WebKit browsers include Safari, Opera, Steam Browser, Midori, S60 (Symbian), Blackberry Browser and Playstation 3's browser - but not Firefox, Internet Explorer or Edge.
This bug has now been fixed in Chrome 45.0.2454.101 as Deltik points out.
More about what happens
The problem is related to the URL canonicalizer, which runs as soon as you hover over a link - possibly for displaying the link in the status bar of the browser, and for prefetching the webpage so it loads faster once clicked.
As for the role of the URL canonicalizer:
When a URL is written in
HTML, it may be written in a form such as
../../home, but browsers need to translate this URL to something with a protocol and a domain too, like
http://superuser.com/home. Furthermore the URL may contain URL Escapes that need to be translated, and these escapes are percent encoded, like
%%30%30. (A more exhaustive list of URL escapes here).
The functionality handling this URL translation is what's ending up crashing, because it receives input the developers did not expect/handle.
Here's a summary of the code change that fixed the problem:
Correctly handle problematic nested escapes in URL paths.
Specifically, if unescaping in the input leads to the output URL
containing a new escaped sequence, e.g. converting the input "%%30%30"
to "%00", escape the leading '%' as "%25" to ensure the output
sequence is not treated as a new valid escape sequence.
This ensures that canonicalizing the same URL a second time won't make
changes to it, which is important for avoiding crashes and other bugs
in a variety of places in both debug and release builds.