Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Predator did not provide any possible suspects.

Using CL resgression range for the file, "payment_request_spec.cc" assigning to the concern owner.

Suspecting Commit : https://chromium.googlesource.com/chromium/src/+/092e716b1783901cc0be8ef2b8307e7a82866c3d

jinho.bang@/ kinuko@ -- Could you please look into the issue, kindly re-assign if this is not related to your changes.


Thank You.

Okay I'll check this issue.

Hmm, how can I reproduce this issue? (I downloaded minimized test-cases and build with is_asan=true but I didn't reproduce it)
It seems strange to me. Looking into the callstack, the shipping_address_.reset() causes null-pointer dereferencing but the shipping_address_ member is mojo StructPtr and it uses unique_ptr internally. So, even if shipping_address_'s internal pointer is null, calling reset() is no problem. Moreover, we are already doing null checks in all places before using the pointer. Am I missing something?

ClusterFuzz has detected this issue as fixed in range 616628:616630.

Detailed report: https://clusterfuzz.com/testcase?key=4872723313197056

Fuzzer: mojo_fuzzer
Job Type: linux_asan_chrome_mojo
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000158
Crash State:
  payments::mojom::PaymentRequestStubDispatch::Accept
  mojo::InterfaceEndpointClient::HandleValidatedMessage
  mojo::internal::MultiplexRouter::ProcessIncomingMessage
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mojo&range=589365:589367
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mojo&range=616628:616630

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4872723313197056

See https://github.com/google/clusterfuzz-tools for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 4872723313197056 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.