Hi thanks for your bug report, can you also provide the "Uploaded Crash Report ID" - this will be a hex number and looks a bit like this -> 1021c5ceca0ab42a

Thank you for your reply.

Crash report ID 4201b665852baa5a has been uploaded (local crash ID: 42d81f05-1dbb-4150-a94a-058df6caf6a5)
A crash report was created on Tuesday, October 16, 2018 at 4:33:02 and was uploaded to Tuesday, October 16, 2018 at 4:33:04

I am Japanese, so the time shown in this report is "Asia / Tokyo".

Thank you for providing more feedback. Adding the requester to the cc list.

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

This is crashing in autofill::i18n::ParsePhoneNumber.

estade - can you take a look at this?

Please can you consider writing a fuzzer for ParsePhoneNumber as well?

--

Thread 0 (id: 0x1a94) CRASHED [Unhandled C++ Exception @ 0x00007ff94389a388 ] MAGIC SIGNATURE THREAD
Stack Quality100%Show frame trust levels
0x00007ff94389a388	(KERNELBASE.dll + 0x0003a388 )	RaiseException
0x00007ff90b2455bc	(chrome.dll -throw.cpp:131 )	CxxThrowException
0x00007ff90b223bd9	(chrome.dll -xthrow.cpp:23 )	std::_Xout_of_range(char const *)
0x00007ff908e7be6b	(chrome.dll -xstring:1829 )	std::_String_val<std::_Simple_types<char> >::_Xran()
0x00007ff9087a0cab	(chrome.dll -xstring:2617 )	std::basic_string<char,std::char_traits<char>,std::allocator<char> >::assign(std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &,unsigned __int64,unsigned __int64)
0x00007ff90ae3f5eb	(chrome.dll -phone_number_i18n.cc:173 )	autofill::i18n::ParsePhoneNumber(std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > const &,std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > *,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > *,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > *,std::basic_string<char,std::char_traits<char>,std::allocator<char> > *,i18n::phonenumbers::PhoneNumber *)
0x00007ff90ae40683	(chrome.dll -phone_number_i18n.cc:330 )	autofill::i18n::PhoneObject::PhoneObject(std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > const &,std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &)
0x00007ff90aa71ad4	(chrome.dll -phone_number.cc:205 )	autofill::PhoneNumber::UpdateCacheIfNeeded(std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &)
0x00007ff90aa71b68	(chrome.dll -phone_number.cc:190 )	autofill::PhoneNumber::SetInfoImpl(autofill::AutofillType const &,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > const &,std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &)
0x00007ff90aa6fc87	(chrome.dll -autofill_profile.cc:858 )	autofill::AutofillProfile::SetInfoImpl(autofill::AutofillType const &,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > const &,std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &)
0x00007ff90ac1952a	(chrome.dll -form_data_importer.cc:340 )	autofill::FormDataImporter::ImportAddressProfileForSection(autofill::FormStructure const &,std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &)
0x00007ff90ac19110	(chrome.dll -form_data_importer.cc:266 )	autofill::FormDataImporter::ImportAddressProfiles(autofill::FormStructure const &)
0x00007ff90ac187b1	(chrome.dll -form_data_importer.cc:238 )	autofill::FormDataImporter::ImportFormData(autofill::FormStructure const &,bool,bool,bool,std::unique_ptr<autofill::CreditCard,std::default_delete<autofill::CreditCard> > *)
0x00007ff90ac186b4	(chrome.dll -form_data_importer.cc:126 )	autofill::FormDataImporter::ImportFormData(autofill::FormStructure const &,bool,bool)
0x00007ff90a80ea2f	(chrome.dll -autofill_manager.cc:387 )	autofill::AutofillManager::OnFormSubmittedImpl(autofill::FormData const &,bool,autofill::SubmissionSource,base::TimeTicks)
0x00007ff908d842b1	(chrome.dll -autofill_driver.mojom.cc:824 )	autofill::mojom::AutofillDriverStubDispatch::Accept(autofill::mojom::AutofillDriver *,mojo::Message *)
0x00007ff9087edcba	(chrome.dll -multiplex_router.cc:868 )	mojo::internal::MultiplexRouter::ProcessIncomingMessage(mojo::internal::MultiplexRouter::MessageWrapper *,mojo::internal::MultiplexRouter::ClientCallBehavior,base::SequencedTaskRunner *)
0x00007ff9087ed800	(chrome.dll -multiplex_router.cc:590 )	mojo::internal::MultiplexRouter::Accept(mojo::Message *)
0x00007ff9087ecfad	(chrome.dll -connector.cc:456 )	mojo::Connector::ReadSingleMessage(unsigned int *)
0x00007ff9087ece28	(chrome.dll -connector.cc:486 )	mojo::Connector::ReadAllAvailableMessages()
0x00007ff9087ecd12	(chrome.dll -simple_watcher.cc:273 )	mojo::SimpleWatcher::OnHandleReady(int,unsigned int,mojo::HandleSignalsState const &)
0x00007ff90872423b	(chrome.dll -task_annotator.cc:101 )	base::debug::TaskAnnotator::RunTask(char const *,base::PendingTask *)
0x00007ff908723c36	(chrome.dll -message_loop.cc:421 )	base::MessageLoop::RunTask(base::PendingTask *)
0x00007ff90871cbe7	(chrome.dll -message_loop.cc:480 )	base::MessageLoop::DoWork()
0x00007ff90881a808	(chrome.dll -message_pump_win.cc:171 )	base::MessagePumpForUI::DoRunLoop()
0x00007ff90871c8cd	(chrome.dll -message_pump_win.cc:52 )	base::MessagePumpWin::Run(base::MessagePump::Delegate *)
0x00007ff90871c630	(chrome.dll -run_loop.cc:102 )	base::RunLoop::Run()
0x00007ff908ae4c0d	(chrome.dll -chrome_browser_main.cc:2086 )	ChromeBrowserMainParts::MainMessageLoopRun(int *)
0x00007ff908ae4a11	(chrome.dll -browser_main_loop.cc:1034 )	content::BrowserMainLoop::RunMainMessageLoopParts()
0x00007ff908ae49bc	(chrome.dll -browser_main_runner_impl.cc:162 )	content::BrowserMainRunnerImpl::Run()
0x00007ff9093885ad	(chrome.dll -browser_main.cc:47 )	content::BrowserMain(content::MainFunctionParams const &)
0x00007ff9098baafe	(chrome.dll -content_main_runner_impl.cc:596 )	content::RunBrowserProcessMain(content::MainFunctionParams const &,content::ContentMainDelegate *)
0x00007ff9098baeb0	(chrome.dll -content_main_runner_impl.cc:947 )	content::ContentMainRunnerImpl::Run(bool)
0x00007ff908705a4a	(chrome.dll -main.cc:472 )	service_manager::Main(service_manager::MainParams const &)
0x00007ff908705647	(chrome.dll -content_main.cc:19 )	content::ContentMain(content::ContentMainParams const &)
0x00007ff908701e59	(chrome.dll -chrome_main.cc:101 )	ChromeMain
0x00007ff6ab27372b	(chrome.exe -main_dll_loader_win.cc:201 )	MainDllLoader::Launch(HINSTANCE__ *,base::TimeTicks)
0x00007ff6ab271698	(chrome.exe -chrome_exe_main_win.cc:230 )	wWinMain
0x00007ff6ab334a71	(chrome.exe -exe_common.inl:283 )	__scrt_common_main_seh
0x00007ff945583033	(KERNEL32.DLL + 0x00013033 )	BaseThreadInitThunk
0x00007ff946b71460	(ntdll.dll + 0x00071460 )	RtlUserThreadStart

Fabio, could you find the best person to look at this?

FYI: The fuzzer is in https://crrev.com/c/1286453.
I still try to reduce its build dependencies, and also am investigating whether the crash it already found is the same as here or something else.

The crash I'm seeing from the fuzzer (CL in #9, crash case attached) has the following similar but different stack trace. Nevertheless, dvadym@ mentioned creating a quick fix to stop crashes which might fix both, so I'll wait for that and re-run the fuzzer to see if I have a yet another instance.

Also, I won't try to slim down the fuzzer dependency on autofill's core/browser:browser, because we already have fuzzers which depend on that.

The stack I saw was:
 out/libfuzzer/autofill_phone_number_i18n_fuzzer ./crash-0e813cc7116e6f97fa0af918c7c62b6ac8b84795
INFO: Seed: 933393921
INFO: Loaded 1 modules   (900098 inline 8-bit counters): 900098 [0x93b0030, 0x948bc32),
INFO: Loaded 1 PC tables (900098 PCs): 900098 [0x948bc38,0xa247c58),
out/libfuzzer/autofill_phone_number_i18n_fuzzer: Running 1 inputs 1 time(s) each.
Running: ./crash-0e813cc7116e6f97fa0af918c7c62b6ac8b84795
UTF-8 buffer is not interchange-valid.==78551== ERROR: libFuzzer: deadly signal
    #0 0x2240297 in __sanitizer_print_stack_trace /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm/compiler-rt/lib/asan/asan_stack.cc:38:3
    #1 0x22c0dfb in fuzzer::PrintStackTrace() third_party/libFuzzer/src/FuzzerUtil.cpp:206:5
    #2 0x2289a1c in fuzzer::Fuzzer::CrashCallback() third_party/libFuzzer/src/FuzzerLoop.cpp:237:3
    #3 0x22899a9 in fuzzer::Fuzzer::StaticCrashSignalCallback() third_party/libFuzzer/src/FuzzerLoop.cpp:209:6
    #4 0x7fdbe7a5a0bf  (/lib/x86_64-linux-gnu/libpthread.so.0+0x110bf)
    #5 0x42d7fdd in __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) buildtools/third_party/libc++abi/trunk/src/cxa_exception.cpp:153:5
    #6 0x42d7ed4 in __cxa_throw buildtools/third_party/libc++abi/trunk/src/cxa_exception.cpp:285:5
    #7 0x42c96db in __throw_out_of_range buildtools/third_party/libc++/trunk/include/stdexcept:236:5
    #8 0x42c96db in std::__1::__basic_string_common<true>::__throw_out_of_range() const buildtools/third_party/libc++/trunk/include/string:611
    #9 0x42c9e38 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned long, unsigned long, std::__1::allocator<char> const&) buildtools/third_party/libc++/trunk/include/string:1939:15
    #10 0x43191e6 in substr buildtools/third_party/libc++/trunk/include/string:3239:12
    #11 0x43191e6 in autofill::i18n::ParsePhoneNumber(std::__1::basic_string<unsigned short, base::string16_internals::string16_char_traits, std::__1::allocator<unsigned short> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<unsigned short, base::string16_internals::string16_char_traits, std::__1::allocator<unsigned short> >*, std::__1::basic_string<unsigned short, base::string16_internals::string16_char_traits, std::__1::allocator<unsigned short> >*, std::__1::basic_string<unsigned short, base::string16_internals::string16_char_traits, std::__1::allocator<unsigned short> >*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, i18n::phonenumbers::PhoneNumber*) components/autofill/core/browser/phone_number_i18n.cc:173
    #12 0x2267037 in LLVMFuzzerTestOneInput components/autofill/core/browser/phone_number_i18n_fuzzer.cc:41:23
    #13 0x228cab5 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) third_party/libFuzzer/src/FuzzerLoop.cpp:570:15
    #14 0x2270205 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) third_party/libFuzzer/src/FuzzerDriver.cpp:280:6
    #15 0x22767ef in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) third_party/libFuzzer/src/FuzzerDriver.cpp:713:9
    #16 0x229db5c in main third_party/libFuzzer/src/FuzzerMain.cpp:20:10
    #17 0x7fdbe1f942b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

Deleted: crash-0e813cc7116e6f97fa0af918c7c62b6ac8b84795 21 bytes

crash-0e813cc7116e6f97fa0af918c7c62b6ac8b84795 21 bytes View Download

Vadym has a quick fix in https://crrev.com/c/1286136 which so far avoids all the issues the fuzzer from https://crrev.com/c/1286453 was aware of (fuzzer still running on my machine at the moment).

The quick fix just stops the crashes, but if we want the code to actually work with non-ASCII stuff, more investment would be needed.

I've made some investigations.

1.For parsing string to phone, open source library libphonenumber is used https://github.com/googlei18n/libphonenumber (this is Google open source project).

2.As far as I understand, this library has some sophisticated support of parsing international numbers even when the numbers are with non-ASCII characters. So the string from reproduction example is recognized to be similar to phone numbers.

3.libphonenumber converts the string to ASCII digits (10 zeros for this examples, that makes sense), but libphonenumber function GetLengthOfNationalDestinationCode returns that national code has length 12 (that might be the length of Unicode string in bytes).

4.There is an attempt to get prefix of length national code (12 here) from phone (size 10), and that crashes the browser process.

The quick fix is in commit queue https://chromium-review.googlesource.com/c/chromium/src/+/1286136 (it's just giving up to parse phone number if national length is bigger than the phone number). But it probably makes sense to made some fixes in libphonenumber.

Code references:
1. ParsePhoneNumber function https://cs.chromium.org/chromium/src/components/autofill/core/browser/phone_number_i18n.cc?type=cs&q=+ParsePhoneNumber&sq=package:chromium&g=0&l=128

2. The call of GetNationalSignificantNumber inside ParsePhoneNumber returns ASCII representation of the phone number

3.The call of GetLengthOfNationalDestinationCode inside ParsePhoneNumber returns incorrect nationa code length.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fd86da2f030895099c2f5b59b1f64a71eacc327c

commit fd86da2f030895099c2f5b59b1f64a71eacc327c
Author: Vadym Doroshenko <dvadym@chromium.org>
Date: Wed Oct 17 12:57:26 2018

Quick fix for crash during phone parsing.

This CL fixes out of range access, when by some reasons during the
phone parsing, libphonenumber returns that national code is longer that
the parsed string. Probably the reasons are some incorrect treating of
non-ASCII characters.

Bug:  895578 
Change-Id: I2f0a7622453191778907a8f54e74e35a1484765b
Reviewed-on: https://chromium-review.googlesource.com/c/1286136
Commit-Queue: Vadym Doroshenko <dvadym@chromium.org>
Reviewed-by: Vaclav Brozek <vabr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#600366}
[modify] https://crrev.com/fd86da2f030895099c2f5b59b1f64a71eacc327c/components/autofill/core/browser/phone_number_i18n.cc

Assigning to dvadym@ since he sent a CL to fix that.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/57d7dded44f76ed86c845232d22b678fdb441e46

commit 57d7dded44f76ed86c845232d22b678fdb441e46
Author: Vaclav Brozek <vabr@chromium.org>
Date: Wed Oct 17 18:56:45 2018

Add a fuzzer for phone_number_i18n

The fuzzer was able to exercise the codepath causing the crash
from the associated bug report (causing an out-of-range error
in std::basic_string due to length computed incorrectly because
of an error in Unicode handling).

Bug:  895578 
Change-Id: Icbef8120c18c89227ba7a94c410ec58948d13ae6
Reviewed-on: https://chromium-review.googlesource.com/c/1286453
Commit-Queue: Vaclav Brozek <vabr@chromium.org>
Reviewed-by: Max Moroz <mmoroz@chromium.org>
Reviewed-by: Fabio Tirelo <ftirelo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#600503}
[modify] https://crrev.com/57d7dded44f76ed86c845232d22b678fdb441e46/components/autofill/core/browser/BUILD.gn
[add] https://crrev.com/57d7dded44f76ed86c845232d22b678fdb441e46/components/autofill/core/browser/phone_number_i18n_fuzzer.cc
[add] https://crrev.com/57d7dded44f76ed86c845232d22b678fdb441e46/components/autofill/core/browser/phone_number_i18n_fuzzer.dict

I am moved by the wonderful work of the Chromium team. Thank you very much.

It may already be useless, but I will attach a test file.
This is a little added to the first attachment.
"00-0000-0000" is set as "value" as shown below.
<input id="your-tel" class="form-input" type="text" name="your-tel" maxlength="32" placeholder="例) 00-0000-0000" value="００－００００－００００" />

Even if submitting in this case, the chrome browser will not crash.
However, after deleting one "０" and submitting it, the browser crashes.
You may already be aware, but I will send this for just in case.

Thanks for further details in #16.
I am not sure if I understood the reproduction steps for the further crash. I used Chrome version 72.0.3585.0 (locally built) on GNU/Linux and did these steps:
(1) Staged the index.html from #16 on a local webserver (serving http://localhost)
(2) Navigated to that file, submitted.
(3) Navigated to that file again, deleted the first "０", submitted.
(4) Navigated to that file again, deleted the second "０" (so that the string was "－００００－００００"), submitted.
(5) Navigated to that file again, deleted all but one "－", submitted.

In none of the cases I experienced a crash. Am I doing something wrong?

I've filed a libphoneutil bug b/117926975

Thank you for checking.
The things I wanted to tell you are the following.
1) Open the file I attached -> send without doing anything -> browser will not crash
2) Open the file I attached -> delete a bit of string -> browser will crash

e.g.) String when the browser crashes
０－００００－００００
００－００００－００
００－０００－００００

e.g.) String when the browser does not crash
００－０００－００
００００００００００
００－００００００００

The result I confirmed was this.

--------------------------------------------------------------

I did the same test on the old 32bit OS (Windows 10 Home).
The browser(CHROME VERSION: 45.0.2454.101) did not crash.

After that, I upgraded the chrome browser version(70.0.3538.67).
The browser did not crash.
Even after rebooting, the result was the same.

Will these results help you?

I'm sorry.
I forgot to write one step.

2) Open the file I attached -> delete a bit of string -> [submit] -> browser will crash

Thanks for the further information in #20 and #21.

However, you appear to be testing with Chrome which does not have the patch from #13. That is only included in 72.0.3584.0 and newer so far (i.e., Chrome Canary).

We'd like to merge CL https://chromium-review.googlesource.com/c/1286136. Which fixes this security related crash.

Please mark security bugs as fixed as soon as the fix lands, and before requesting merges. This update is based on the merge- labels applied to this issue. Please reopen if this update was incorrect.

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

+awhalley@ (Security TPM) for M71 merge review

I downloaded and used the version of Canarya(72.0.3585.0).
I started XAMMP and tried sending mail from the local host (http://localhost).
The browser never crashed.
Of course, there was no problem with the output mail.

I am very grateful to the Chromium Team. Thank you!

Your change meets the bar and is auto-approved for M71. Please go ahead and merge the CL to branch 3578 manually. Please contact milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

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

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/96714fbc331e2fbad8928618373a30e780280cac

commit 96714fbc331e2fbad8928618373a30e780280cac
Author: Vadym Doroshenko <dvadym@chromium.org>
Date: Sat Oct 20 12:44:55 2018

[M71] Quick fix for crash during phone parsing.

This CL fixes out of range access, when by some reasons during the
phone parsing, libphonenumber returns that national code is longer that
the parsed string. Probably the reasons are some incorrect treating of
non-ASCII characters.

TBR=dvadym@chromium.org

Bug:  895578 
Change-Id: I2f0a7622453191778907a8f54e74e35a1484765b
Reviewed-on: https://chromium-review.googlesource.com/c/1286136
Commit-Queue: Vadym Doroshenko <dvadym@chromium.org>
Reviewed-by: Vaclav Brozek <vabr@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#600366}(cherry picked from commit fd86da2f030895099c2f5b59b1f64a71eacc327c)
Reviewed-on: https://chromium-review.googlesource.com/c/1292871
Cr-Commit-Position: refs/branch-heads/3578@{#183}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/96714fbc331e2fbad8928618373a30e780280cac/components/autofill/core/browser/phone_number_i18n.cc

Ad #26 -- thanks for checking on 72! (And for the report in the first place!)

Merged now to 71, but it will still take some time until the change is propagated to the released Chrome version 71.

Thank you for your kindness.
and thank you for reading my funny English writing.
I am looking forward to the release of version 71.
Of course, I will never leak this issue.

Can somebody from the security team assess whether this bug is critical enough to merge it to M-70 stable?

hi inferno@, since you've been in this bug a bit already, mind giving an assessment re comment 32?

On the website of Japan, "00-0000-0000" is often used as an example of entering a telephone number.
The user actually typing in this number with Full-width is a website administrator and a user who likes mischief.

Users in Japan may enter Full-width and Half-width characters without distinguishing them in the transmission form.
Also, most of the form side is also designed to accept without regard to Half-width and Full-width.

This is the Japanese submission form I know as a web creator.
I am glad if it becomes one material for deciding the update.

Thank you for taking the time to read my comment.

The following revision refers to this bug: 
https://chromium.googlesource.com/chromium/src.git/+/96714fbc331e2fbad8928618373a30e780280cac

Commit: 96714fbc331e2fbad8928618373a30e780280cac
Author: dvadym@chromium.org
Commiter: vabr@chromium.org
Date: 2018-10-20 12:44:55 +0000 UTC

[M71] Quick fix for crash during phone parsing.

This CL fixes out of range access, when by some reasons during the
phone parsing, libphonenumber returns that national code is longer that
the parsed string. Probably the reasons are some incorrect treating of
non-ASCII characters.

TBR=dvadym@chromium.org

Bug:  895578 
Change-Id: I2f0a7622453191778907a8f54e74e35a1484765b
Reviewed-on: https://chromium-review.googlesource.com/c/1286136
Commit-Queue: Vadym Doroshenko <dvadym@chromium.org>
Reviewed-by: Vaclav Brozek <vabr@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#600366}(cherry picked from commit fd86da2f030895099c2f5b59b1f64a71eacc327c)
Reviewed-on: https://chromium-review.googlesource.com/c/1292871
Cr-Commit-Position: refs/branch-heads/3578@{#183}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}

I was worried whether I should report this.
Because, it is already closed here.
And that is because I have confirmed again that this issue will not occur in Canary (72.0.3591.1).
However, I think reporting is my duty, so I will report it.

Since the stable version (70.0.3538.77) of the chrome browser has been updated, I checked again with the file attached in the report of # 1.
As far as I remember, when I reported # 1, the same issue did not occur in the fax entry field.
However, in the current version (70.0.3538.77), the same issue as the TEL input field occurs even in the fax input field.
If you change the name attribute in the fax entry field from "your-fax" to "your-fox", this issue will not occur.
So I think that it may be an issue with the same origin.
I sent a crash report just in case.
Crash ID: crash/fa17286d9c3c8db7
Thank you for taking the time to read this comment.

Sorry ... I made a mistake while fighting 'Google Translate'.
please Ignore "# 1". I should have expressed it as "My first report".

It's the same crash, fix it in 71.0.3578.20 (the current beta).

Friendly ping security team, do we need it merge it to stable? I'm happy to provide more information or chat.

dvadym@ - pardon the delay. No need to merge back to 70, thanks for getting it into 71.

iso.forcontact@ - the VRP panel looked at this and aren't certain of the exploitability of the bug. Would you be able to outline how you could see this crash leading to an exploit?

awhalley@ Thanks for checking!

For "The exploitability of the bug", is it okay with such attachments?
The file attached here is a little edited version of the file I first attached.
Use: HTML, JavaScript, CSS, Cookie (Code that is often used in non-malicious simple)
Note: Since crashes can not be reproduced in other browsers, conditions are set by user agents.
Note: Third party videos are embedded from youtube, so delete this file later.

First, I will explain this file.
1. The form part is hidden with CSS. Instead, the cat's video is displayed.
2. In the first access, "00-0000-0000" is automatically entered in the "TEL input field" when loading the page.
3. The page records what you visited in Cokkie, but this page will be closed after 30 seconds by Crash Browser crash.
4. When restarting and restoring the browser, the cookie shows that it is the second visit and the contents hidden by CSS and javascript will appear. (Of course it is also possible to move to any page with "location.href".)

Next, I will consider the visitor's feelings and actions.
"Oh, I love cats! I see the video!"
Unfortunately, after 30 seconds, the chrome browser crashes.
The Chrome Browser is an easy-to-use, general browser that will not crash under normal usage, so users will be surprised.
The user who wants to see the continuation of the video restores the tab.
Then fake content is displayed.
If fake content is clever, users surprised by browser crashes will be easy to deceive.

Finally, I will consider how this issue will be affected.
· This issue does not occur in Edge and Firefox. So the trust of chrome browser will be lost.
· Browser crash is abnormal. So it makes it easy to cheat users who are anxious. This means that fraud is easier.
· Since only Chrome Browser crashes, it will be easier to create a fraudulent site aimed at capturing Google accounts.
· In Japan, the number "00-0000-0000" is common as an example of entering a phone number or fax number.
So, if someone else discovered this, and someone made it public on Twitter etc., it may be treated as burst of laughter at least in Japan.

I do not have advanced skills, so I do not know enough about this level of explanation. I'm sorry….
Thank you for taking the time to read this Long message.

My comment on Comment 44 was totally misplaced.I'm embarrassed.
I'm sorry I confused you.
I think that it is unnecessary information and I deleted it.

I apologize for my late thanks.
dvadym @ Thank you for always checking.
awhalley @ Thank you for leading me.
Thank you for security team for your hard work on an excellent browser.

Thank you for all the details iso.forcontact@. We are very glad that we fixed this, so thanks again for the report. In asking about exploitability, we were interested in how an attacker could use the crash to gain additional benefit, e.g. gaining code execution. Unfortunately as we can't see how an attacker could do this, we won't be rewarding for this bug. Thanks again!

What I was most concerned about was the brand risk of Google and Chrome browser.
I do not want to see the news like "Chrome browser crash when entering a phone number entry example #lol".
So I reported this issue.
I am neither a bounty hunter nor a hacker.
So I'm not familiar with "exploitability". sorry.

I am purely pleased that this issue has been fixed.
Thank you, Chromium Team.
Thank you, Google Translate.

By the way, I have one question.
May I share this issue with my team?
All the websites I manage solve this issue, but it has not been solved yet on websites managed by members other than me.
Until version 71 (stable version) is released, we have to make a website that does not crash the chrome browser.

hi iso.forcontact@ - yep you are free to share with your team. In fact, given we're not tracking this as a security bug I'm making it public.  Cheers!