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

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

Automatically adding ccs based on suspected regression changelists:

TrustedTypes: Added TrustedTypes.getPolicyNames & minor changes by orsibatiz@google.com - https://chromium.googlesource.com/chromium/src/+/136008de5d2e0b2e1913bcbcbd641b2bd4158bee

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label.

This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

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

orsibatiz@, I'm moving the discussing here just in case it could be useful to anyone else.

1) Uninitialized value was created by an allocation of 'action_index_int' in the stack frame of function '_ZN11test_runner18TestRunnerBindings28SimulateWebNotificationClickEPN3gin9ArgumentsE'
#0 0x21a74640 in test_runner::TestRunnerBindings::SimulateWebNotificationClick(gin::Arguments*) content/shell/test_runner/test_runner.cc:1302

if we look into that code: https://chromium.googlesource.com/chromium/src/+/00bae57a63afb88b0b425691e34842c050413052/content/shell/test_runner/test_runner.cc#1315

we can see that `action_index_int` is created, then it's passed to `args->GetNext()` for initialization, and after that gets used in the assignment to `action_index`

that line is also present in the stacktrace -- good sign

```
#5 0x21a75646 in test_runner::TestRunnerBindings::SimulateWebNotificationClick(gin::Arguments*) content/shell/test_runner/test_runner.cc:1318
```

2) if we dive into `args->GetNext()` and deeper, we can see that it all narrows down to the following code: https://cs.chromium.org/chromium/src/gin/converter.cc?sq=package:chromium&g=0&l=30

which might `return false` and do not initialize the value we want it to initialize -- very likely that's the case and the reason why MemorySanitizer complains

3) looking at the blame results, none of these two places was changed recently:

- https://chromium.googlesource.com/chromium/src/+blame/95cc1cb651bf078a6dc95ce3ac2a9c263fcaeb98/content/shell/test_runner/test_runner.cc#1315
- https://chromium.googlesource.com/chromium/src/+blame/95cc1cb651bf078a6dc95ce3ac2a9c263fcaeb98/gin/converter.cc#29

so the issue must be somewhere else.

I see that we don't check the result of `args->GetNext()` which seems wrong to me, we should be doing something like the following:

    if (args->GetNext(&action_index_int)) 
    	action_index = action_index_int;
    else
    	// I don't know, either ignore or do some error?

So, I think that your change did not introduce a bug, but helped to detect an existing issue.

Assigning to peter@ as I suspect https://chromium.googlesource.com/chromium/src/+/988ef967a4502948dda95c811701c3cdc518184e should have checks for the return value of `args->GetNext()`

ClusterFuzz has detected this issue as fixed in range 587533:587534.

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

Fuzzer: inferno_twister
Job Type: linux_msan_content_shell_drt
Platform Id: linux

Crash Type: Use-of-uninitialized-value
Crash Address: 
Crash State:
  void base::Pickle::WriteBytesStatic<4ul>
  IPC::TupleParamTraitsHelper<std::__1::tuple<std::__1::basic_string<char, std::__
  IPC::MessageT<LayoutTestHostMsg_SimulateWebNotificationClick_Meta, std::__1::tup
  
Sanitizer: memory (MSAN)

Recommended Security Severity: Medium

Regressed: https://clusterfuzz.com/revisions?job=linux_msan_content_shell_drt&range=586629:586630
Fixed: https://clusterfuzz.com/revisions?job=linux_msan_content_shell_drt&range=587533:587534

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

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 6494529163886592 is verified as fixed, so closing issue as verified.

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

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