CHECK failure: false in scoped_handle_verifier.cc |
|||||||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=5063560042119168 Fuzzer: libFuzzer_mojo_core_node_channel_fuzzer Fuzz target binary: mojo_core_node_channel_fuzzer Job Type: windows_libfuzzer_chrome_asan Platform Id: windows Crash Type: CHECK failure Crash Address: Crash State: false in scoped_handle_verifier.cc base::win::internal::ScopedHandleVerifier::CloseHandle base::win::GenericScopedHandle<base::win::HandleTraits,base::win::VerifierTraits Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=windows_libfuzzer_chrome_asan&range=611580:611589 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5063560042119168 Issue filed automatically. See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing_on_windows.md for more information.
,
Dec 14
Automatically applying components based on crash stacktrace and information from OWNERS files. If this is incorrect, please apply the Test-Predator-Wrong-Components label.
,
Dec 14
The documentation for reproducing on Windows has been moved to https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md
,
Dec 20
,
Dec 20
,
Dec 20
,
Dec 26
Friendly ping to look into this issue and to provide further update on this issue as it has been marked as a stable blocker. Thanks!
,
Jan 2
This is tagged as M-72 Beta blocker as per https://clusterfuzz.com/testcase-detail/5063560042119168. Next M-72 beta release is going to be next week. rockot@: Could you please review the blocker label for this and update. Thank you!
,
Jan 2
rockot@ is OOO until Jan 7th. From the change log (https://chromium.googlesource.com/chromium/src/+log/cbfb29fbd689837cc2f90240388f56b5baab2821..f14ab187f632ec16f6ded4f1b3fa4158694c2f1f?pretty=fuller&n=10000), this change (https://chromium.googlesource.com/chromium/src/+/69ad26ad8086df04cffc98b1c5b43752a47e8b06) seems to be related? leon.han@, any thoughts here? + kinuko@ and haraken@ (Reviewers for the above CL) Thank you!
,
Jan 3
This should be a problem on M72 with the same root cause as issue 909713 . The culprit is https://chromiumdash.appspot.com/commit/24170150bbeeecdae6edc86ae98ad9c9fca77aa8, which landed before M72 branch cut point so it's carried into M72. The fix is https://chromiumdash.appspot.com/commit/fada5812d8c5cfd49fb05cdefe77c703997a687e, which only landed on Master. So I believe we just need to merge the fix into M72 branch.
,
Jan 3
This bug requires manual review: M72 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: govind@(Android), kariahda@(iOS), djmm@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 3
,
Jan 3
thanks leon.han@ rockot@ can you please confirm if https://chromiumdash.appspot.com/commit/fada5812d8c5cfd49fb05cdefe77c703997a687e will fix this issue and needs to be merged to m72?
,
Jan 6
I can confirm that it fixes the issue, but not that we should merge to M72. This was not a regression (only an old bug detected by a new fuzzer), and I'm reasonably confident that the only consequence of the bug would be that an attacker could cause a child process to crash from another compromised child process. So pretty low severity.
,
Jan 7
awhalley@ as fyi - Thanks rockot@. I'm rejecting this merge for M72. Let's target 73 for the fix.
,
Jan 13
ClusterFuzz testcase 5063560042119168 is still reproducing on tip-of-tree build (trunk). Please re-test your fix against this testcase and if the fix was incorrect or incomplete, please re-open the bug. Otherwise, ignore this notification and add ClusterFuzz-Wrong label. |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by ClusterFuzz
, Dec 14