csharrison: Could you please help triage? Thanks!

Something is wrong here... re-running the clusterfuzz test.

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

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

I am very confused by this report, and it does not repro on Linux. Punting this to loader for the triager to investigate.

03165229c01b328598a7ba00bfd2d4ab6fa79f0a is in the (small) regression range, so *maybe* it is related, but I am very doubtful. +sigbjornf just as FYI.

Removing some RB labels because I think this may just be a bug in the fuzzer infra.

aarya@, I believe this crash is is happening in ClusterFuzz itself, is that correct?

Using "Security_Severity-Low" but it seems very likely that this is a ClusterFuzz issue.

It wouldn't be a clusterfuzz issue so much as the fuzzer, or maybe instrumentation. I'm honestly not sure what's going on here. It seems unlikely that this is a security bug, but it's hard to say for sure without investigating. If this does turn out to be real it isn't a low, so I'm adjusting the severity back for now. If it's not real, we should remove it from the security queue.

Yes to be clear I was implicating the fuzzer itself., not the fuzzing infrastructure. However, I don't see the bad free in the code.

Security Sheriff notes:
If we agree this looks like a fuzzer or instrumentation issue, perhaps we should update the component.
Also, I think if we want to consider this bug as potentially high severity, we should identify a clear owner but I don't know how to find the right owner here.

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

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

I'm building the fuzzer atm on my Mac, I'll report back if it repros on TOT.

The problem is that blink initialization isn't happening correctly in the fuzzer.

I changed the code to stop using the LLVMFuzzerInitialize function to initialize blink (and instead pull it into the main function) and it seems to work. Did LLVMFuzzerInitialize change?

The "bug" here is we are trying to delete a static string (StringImpl::empty) which should never be destroyed. This is because we never called StringImpl::initStatics (afaict).

Turning on warnings, and I got:
WARNING: Failed to find function "LLVMFuzzerInitialize". Reason dlsym(RTLD_DEFAULT, LLVMFuzzerInitialize): symbol not found.

+kcc, what are we doing wrong in this fuzzer to cause this problem?

Removing security flags because this is just a badly initialized fuzzer.

This just came up again with  issue 724941  where hoisting initialization into the main fuzzer function fixed the problem, and it seemed like LLVMFuzzerInitialize was never getting called.

mmoroz@ would you be able to help out?

Note that this seems to only happen on mac. I'm nervous it means all our Blink libfuzzers running on Mac are broken, though it seems like this particular one surfaces problems more often.

Looking

So, the problem is that LLVMFuzzerInitialize is not being executed on Mac?

I don't see any changes on libFuzzer side (https://chromium.googlesource.com/chromium/llvm-project/llvm/lib/Fuzzer.git) that could lead to this behavior. Can this be a compilation issue caused by, for example, a recent clang roll?

Bad thing that I don't have a Mac to reproduce the issue. 

mmoroz just FYI that this issue is from Feb

Let me know if we can get a libfuzzer expert to own the bug. If we want, I can send a CL to update to using static initialization within LLVMFuzzerTestOneInput.

FYI: sadly, my team does not support libFuzzer on Mac. 
(The Apple folks do support it, and all tests work, and everything seems fine,
but *my* team does not provide any SLA for Mac)

charrison@, yes please. lets workaround this to initialize stuff in LLVMFuzzerTestOneInput itself.

#26 SGTM. Let me own this bug then while I work on the CL. This is the common idiom in Blink so I'll change all the Blink fuzzers.

As per http://llvm.org/docs/LibFuzzer.html#startup-initialization
the recommended way is to *not* use LLVMFuzzerTestOneInput unless you need
argv/argc

Thank you kcc I didn't realize that. All the more reason to update the existing fuzzers.

Let me remove some labels because this isn't a security issue.

Thank you Charles for taking care of this!

Lets keep this bug open since we need to check for other libFuzzers using LLVMFuzzerInitialize with argv (i think v8 has one).

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

commit fda3f3decbf18cec68fed81b8f48add43c3c64b2
Author: csharrison <csharrison@chromium.org>
Date: Fri May 26 13:35:12 2017

Remove LLVMFuzzerInitialize from many Blink fuzzers

This function should only be used if argv is needed, otherwise libfuzzer
best practice is to just use static initialization in
LLVMFuzzerTestOneInput [1].

This CL also changes the BlinkFuzzerTestSupport to be a class which
does all initialization in its constructor.

[1]: http://llvm.org/docs/LibFuzzer.html#startup-initialization

BUG= 693760 

Review-Url: https://codereview.chromium.org/2900373002
Cr-Commit-Position: refs/heads/master@{#474993}

[modify] https://crrev.com/fda3f3decbf18cec68fed81b8f48add43c3c64b2/third_party/WebKit/Source/bindings/core/v8/serialization/SerializedScriptValueFuzzer.cpp
[modify] https://crrev.com/fda3f3decbf18cec68fed81b8f48add43c3c64b2/third_party/WebKit/Source/core/css/StyleSheetContentsFuzzer.cpp
[modify] https://crrev.com/fda3f3decbf18cec68fed81b8f48add43c3c64b2/third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicyFuzzer.cpp
[modify] https://crrev.com/fda3f3decbf18cec68fed81b8f48add43c3c64b2/third_party/WebKit/Source/core/html/parser/HTMLPreloadScannerFuzzer.cpp
[modify] https://crrev.com/fda3f3decbf18cec68fed81b8f48add43c3c64b2/third_party/WebKit/Source/core/html/parser/TextResourceDecoderFuzzer.cpp
[modify] https://crrev.com/fda3f3decbf18cec68fed81b8f48add43c3c64b2/third_party/WebKit/Source/platform/PngFuzzer.cpp
[modify] https://crrev.com/fda3f3decbf18cec68fed81b8f48add43c3c64b2/third_party/WebKit/Source/platform/TextCodecFuzzer.cpp
[modify] https://crrev.com/fda3f3decbf18cec68fed81b8f48add43c3c64b2/third_party/WebKit/Source/platform/WebIconSizesFuzzer.cpp
[modify] https://crrev.com/fda3f3decbf18cec68fed81b8f48add43c3c64b2/third_party/WebKit/Source/platform/feature_policy/FeaturePolicyFuzzer.cpp
[modify] https://crrev.com/fda3f3decbf18cec68fed81b8f48add43c3c64b2/third_party/WebKit/Source/platform/json/JSONParserFuzzer.cpp
[modify] https://crrev.com/fda3f3decbf18cec68fed81b8f48add43c3c64b2/third_party/WebKit/Source/platform/mhtml/MHTMLFuzzer.cpp
[modify] https://crrev.com/fda3f3decbf18cec68fed81b8f48add43c3c64b2/third_party/WebKit/Source/platform/testing/BlinkFuzzerTestSupport.cpp
[modify] https://crrev.com/fda3f3decbf18cec68fed81b8f48add43c3c64b2/third_party/WebKit/Source/platform/testing/BlinkFuzzerTestSupport.h

ClusterFuzz has detected this issue as fixed in range 474986:475005.

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

Fuzzer: libfuzzer_text_resource_decoder_fuzzer
Job Type: mac_libfuzzer_chrome_asan
Platform Id: mac

Crash Type: Bad-free
Crash Address: 0x000117679c80
Crash State:
  blink::LLVMFuzzerTestOneInput
  start
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=mac_libfuzzer_chrome_asan&range=451299:451309
Fixed: https://clusterfuzz.com/revisions?job=mac_libfuzzer_chrome_asan&range=474986:475005

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


See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md 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 6143891498860544 is verified as fixed, so closing issue.

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

Verified -> Available due to fuzzers which really need argv (see #32).

Moving myself to cc

I think this is happening because of LTO added several months ago, as the optional functions are looked up using dlsym by default, but are stripped out of the binary.

Using FuzzerExtFunctionsWeak.cpp rather than FuzzerExtFunctionsDlsym.cpp works for me with no other efforts (just by hand-editing the defines to switch over). Note I also have to revert https://chromium-review.googlesource.com/c/596748 to get fuzzing to work on Mac on recent builds; I'm not sure if Mac fuzzing is maintained at this point.

Similar to 754124, should get fixed after migration to -fsanitize=fuzzer.

For more information, please see https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md.

The link referenced in the description is no longer valid.

(bulk edit)