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 OWNERS file / target commit history.

If this is incorrect, please add ClusterFuzz-Wrong label.

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/34ac4b2fc6f2df2ae7f35f69e0921f01dcd299c0 (Switch //net/ntlm to use base::span<const uint8_t>).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

The root cause of this issue is that the underlying backing of the NtlmBufferWriter changed from an std::string (which always had an implicit buffer of at least 1 byte, the NUL byte) to an std::vector<>, of which an empty vector returns nullptr for .begin().

The returning of nullptr causes CanWrite() to return false now, when previously, CanWrite() would return true - if GetBufferPtr() or .size() == 0.

Simply changing the GetBufferPtr() to also consider length == 0 wouldn't be correct, because there's subsequent explicit memcpy()s, and memcpy() requires both pointers to be valid, even in the case of length = 0.

This requires restructuring the code to avoid the ('noop') memcpy and handle zero-length buffers explicitly during write operations, rather than implicitly through memcpy'ing zero bytes to an empty string that has a NUL terminator.

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

commit 4d94d13235d60ceba91dcbff39a907c01d42db2f
Author: Ryan Sleevi <rsleevi@chromium.org>
Date: Tue May 15 19:52:28 2018

Explicitly handle zero-byte NTLM buffer writes

r558579 changed the backing store of NTLM writes from being a
std::basic_string<uint8_t> to a std::vector<uint8_t>, to better align
with its purpose. This change had the effect of causing .data() to now
return nullptr when .size() == 0, rather than the previous behaviour,
in which .data() would return a 1-byte buffer that was a NUL ('\0')
terminator - the consequence of using std::basic_string<>.

This had the effect on writes which expected zero-byte writes (aka
no-ops) to succeed, in that GetBufferPtr() now returned nullptr, rather
than a valid pointer. Since zero-byte memcpys immediately follow, this
needs to be explicitly handled, as memcpy() requires both pointers be
valid, even for zero-byte writes.

BUG= 843066 

Change-Id: I9ff8f825469142da31abc866c81f0418ae25f93f
Reviewed-on: https://chromium-review.googlesource.com/1059449
Commit-Queue: Ryan Sleevi <rsleevi@chromium.org>
Reviewed-by: Asanka Herath <asanka@chromium.org>
Cr-Commit-Position: refs/heads/master@{#558812}
[modify] https://crrev.com/4d94d13235d60ceba91dcbff39a907c01d42db2f/net/ntlm/ntlm_buffer_reader.cc
[modify] https://crrev.com/4d94d13235d60ceba91dcbff39a907c01d42db2f/net/ntlm/ntlm_buffer_reader_unittest.cc
[modify] https://crrev.com/4d94d13235d60ceba91dcbff39a907c01d42db2f/net/ntlm/ntlm_buffer_writer.cc
[modify] https://crrev.com/4d94d13235d60ceba91dcbff39a907c01d42db2f/net/ntlm/ntlm_buffer_writer_unittest.cc

ClusterFuzz has detected this issue as fixed in range 558798:558818.

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

Fuzzer: libFuzzer_net_ntlm_ntlm_client_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  result in ntlm.cc
  net::ntlm::GenerateNtlmHashV1
  net::ntlm::GenerateNtlmResponseV1WithSessionSecurity
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=558574:558581
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=558798:558818

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

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

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