Whoops, forgot about the OS details:
VERSION
Chrome Version: Version 52.0.2743.82 m + stable (32-bit)
Operating System: Window 8.1 64-bit

Crash ID 137eed7e00000000 (7ac97242-a896-407b-b987-d67d79b1fab1)

Using the following seems to result in a different crash signature:
data:text/html,<a href="chrome://resources/qqqq/../../../../../../../../../../../../../../../../secret/secret.dat" download="q">Click</a>

Note: C:/secret/secret.dat exists. Not sure if that's even relevant


Crash ID 889ee8c200000000 (612cfaec-142d-4452-b989-86929f6223ba)


STACK_TEXT:  
07f4f00c 035543be 0c146770 22ebc868 00000000 chrome_2370000!base::debug::BreakDebugger+0x9
07f4f088 0281cbb5 07f4f0fc 07f4f114 22c712c8 chrome_2370000!content::SharedResourcesDataSource::GetMimeType+0x152
07f4f130 0281c971 22eae870 22ebc868 07f4f164 chrome_2370000!content::URLDataManagerBackend::StartRequest+0x20b
07f4f14c 0281c92b 00000001 07f4f17c 0281c8d5 chrome_2370000!content::URLRequestChromeJob::StartAsync+0x23
07f4f158 0281c8d5 0281c94e 22b07e58 22ebc868 chrome_2370000!base::internal::InvokeHelper<1,void,base::internal::RunnableAdapter<void (__thiscall disk_cache::Eviction::*)(bool)> >::MakeItSo<base::WeakPtr<disk_cache::Eviction>,bool const &>+0x31
07f4f17c 023f1742 22c712b8 07f4f480 0719d428 chrome_2370000!base::internal::Invoker<base::IndexSequence<0,1>,base::internal::BindState<base::internal::RunnableAdapter<void (__thiscall disk_cache::Eviction::*)(bool)>,void __cdecl(disk_cache::Eviction *,bool),base::WeakPtr<disk_cache::Eviction>,bool>,base::internal::InvokeHelper<1,void,base::internal::RunnableAdapter<void (__thiscall disk_cache::Eviction::*)(bool)> >,void __cdecl(void)>::Run+0x2a
07f4f1e0 023f14ff 00000000 07f4f480 ffffffff chrome_2370000!base::debug::TaskAnnotator::RunTask+0x16b
07f4f45c 023f0ee9 07f4f480 750c26e0 071bf750 chrome_2370000!base::MessageLoop::RunTask+0x20f
07f4f568 023f0a0c 00000000 071bf750 00000000 chrome_2370000!base::MessageLoop::DoWork+0x42e
07f4f658 023f0934 07f4f6c0 0719d428 0719d428 chrome_2370000!base::MessagePumpForIO::DoRunLoop+0xcd
07f4f684 023f0753 0719d428 0719d428 0719d1f8 chrome_2370000!base::MessagePumpWin::Run+0x55
07f4f6b0 023f0647 00000000 00000000 0719d428 chrome_2370000!base::RunLoop::Run+0x94
07f4f6dc 024d5462 0719d428 0719d1f8 00000000 chrome_2370000!base::Thread::Run+0x23
07f4f7ac 02499d83 0719d428 0719d204 00000000 chrome_2370000!content::BrowserThreadImpl::IOThreadRun+0x22
07f4f7c4 023ef118 0719d428 071c59a0 750c18e0 chrome_2370000!content::BrowserThreadImpl::Run+0x93
07f4f800 023eee60 023eedd5 023eedd5 071c59a0 chrome_2370000!base::Thread::ThreadMain+0x1db
07f4f824 750c7c04 071c59a0 750c7be0 9ab26cbb chrome_2370000!base::`anonymous namespace'::ThreadFunc+0x8b
07f4f838 774eab8f 071c59a0 98f02bdf 00000000 KERNEL32!BaseThreadInitThunk+0x24
07f4f880 774eab5a ffffffff 774cfffe 00000000 ntdll!__RtlUserThreadStart+0x2f
07f4f890 00000000 023eedd5 071c59a0 00000000 ntdll!_RtlUserThreadStart+0x1b

Thanks for the report. I can reproduce the crash on M52 linux. It looks like dbeam@ may have made changes to SharedResourcesDataSource recently. 

In terms of severity, this looks like an out of bounds access in the browser process. However a website can't trigger it directly, and clicking the download through the downloads bar isn't enough. It must be clicked through about:downloads. Due to this we may want medium severity, but leaving as high for the moment.

Thank you for the quick response.

I also found a non-crash related issue with the following which I hope can be fixed along this bug:

data:text/html,<a href="%00:%00" download="q">Click</a>

Downloading that will break about:downloads where all other downloads are missing (also some javascript errors occur):

crisper.js:1174 Uncaught Error: Assertion failed

I'll be happy to file another bug for this if needed.

is hitting a NOTREACHED() Security_Severity-High?

https://cs.chromium.org/chromium/src/content/browser/webui/shared_resources_data_source.cc?q=SharedResourcesDataSource::GetMimeType&sq=package:chromium&dr=CSs&l=145

dbeam: I was looking at the stack trace from the original report, which is similar to the stack trace that I was able to reproduce. See the crash report from my release build:  go/crash/b740037e00000000

Does that make sense? Maybe I'm missing something.

Actually it looks like the standard library is catching this and it's part of the API to throw an exception: http://www.cplusplus.com/reference/string/string/substr/
pos: "If this is greater than the string length, it throws out_of_range."

raymes@: yeah, there might be versions of the stack where they throw from empty_string[0] access, but I'm pretty sure that got fixed here:
https://codereview.chromium.org/2020393002/diff/20001/content/browser/webui/shared_resources_data_source.cc

Hello,

Since this turned out to be low severity, is it safe to assume its not eligible for a bounty? 

Thank you

Probably not - there are probably no security implications to this bug. But thank you for finding and filing it with us!

beta has the fix, btw, to only crash in debug mode.

I'd say this might be worth "WontFix"ing.

Will the behavior in Comment 5 be considered for a fix? Do I need to report it separately as a normal bug?

Please file a separate issue for that. Thanks!

dbeam: you might be interested in #5

Done!

Filed  Bug 635220  for the stuff described in Comment #5

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot