Thanks for reporting, khalil!
It seems same SSL error appears on 48.0.2564.109 too.  Is this what you referred as "incorrect"? 
It does look weird (I have no idea what google.com/csi suppose to host), though I don't think it is a chrome's problem or vulnerability (tested on safari as well). 
Could you explain your concern further?  Thanks!

From http://expample.com to google.com/csi -> not allowed
From chrome://newtab to google.com/csi -> allowed

When I use any website "expample.com" then I try to access google.com/csi doesn't navigate, and that's what I expected with chrome://newtab.

I think the omnibox must be empty after trying to access google.com/csi (as I tested on Firefox).

Thanks, Khalil! 
Add component label for better triage. 

I couldn't repro this issue when I tried on incognito window. That's what I expected on simple window.

This is working as intended, and matches Firefox's behavior.  For motivation, see comment 17 of  issue 355537 .  The fix was implemented in https://codereview.chromium.org/232463007/ (in Browser::ShouldPreserveAbortedURLs).

There's a comment explaining it in NavigatorImpl::DidFailProvisionalLoadWithError:

    // However, we do preserve the pending entry in some cases, such as on the
    // initial navigation of an unmodified blank tab. We also allow the
    // delegate to say when it's safe to leave aborted URLs in the omnibox, to
    // let the user edit the URL and try again. This may be useful in cases
    // that the committed page cannot be attacker-controlled. In these cases,
    // we still allow the view to clear the pending entry and typed URL if the
    // user requests (e.g., hitting Escape with focus in the address bar).