The result is a list of CLs that change the crashed files. 

Author: nisse
Project: chromium-webrtc
Changelist: https://chromium.googlesource.com/external/webrtc/trunk/webrtc.git/+/a875ff85398782f352ea722be0c74865f2858ad6
Time: Thu Jan 12 13:15:36 2017
Lines 124 of file socketaddress.cc which potentially caused crash are changed in this cl (frame #3, "rtc::SocketAddress::SetPort").
Minimum distance from crash line to modified line: 0. (file: socketaddress.cc, crashed on: 124, modified: 124).

The crash is from a range check of the port number in SocketAddress::SetPort, called from the SocketAddress constructor. My cl only changes the check from ASSERT to RTC_DCHECK, which probably use sligthly different conditionals.

It's called from https://code.google.com/p/chromium/codesearch#chromium/src/third_party/webrtc/pc/webrtcsdp.cc&sq=package:chromium&type=cs&l=1029

which needs to check that the port number is valid. Taylor, can you have a look, or help assigning to the right person?

I guess it would be good to also have a second look in that file, in case there are any other parts of the sdp input which lack strict input validation, as well as checking all other calls to the SocketAddress constructor.

Yep, I'll add to our bug hotlist.

ClusterFuzz has detected this issue as fixed in range 450309:450324.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=5480884611579904

Fuzzer: libfuzzer_sdp_parser_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: UNKNOWN
Crash Address: 0x03e900004b25
Crash State:
  rtc::FatalMessage::~FatalMessage
  rtc::SocketAddress::SetPort
  rtc::SocketAddress::SocketAddress
  
Sanitizer: address (ASAN)

Regressed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_asan_debug&range=443565:443630
Fixed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_asan_debug&range=450309:450324

Reproducer Testcase: https://cluster-fuzz.appspot.com/download/AMIfv97sDtpiEhIEp08pyosgFLK72c1yVWfykV1EVHeRhQNJtkEuZKbmsvNog5Chr2vfvtkoUGR_AHh9VjlZ0Vqa0BJDfP9S5W9qkCZVQoUJVUdarkqxlk6H2hW1N-k9uXzE3ZLL6X-f8vnA3x1P2YGww9qRhG6zl-N1gkDxemZpLuQ_23dZHZn2svPEZp9gODEEujT9H8gI-3d-C0PNgJhQXEtOuFN0ah0QV_Wc4dBouCA0jYLvf0Af6czTrpLCftMcOovw74yN4MioRVfKmDsk-ouZmX5TpFT-9qRJeZcBvJyC8t07gqYnsTtFv_h9ZIMGfgp-j2L9Miyplit8DzmX2rEkwm3hu-deh_dv1oIIRVBUYE8qZ4s?testcase_id=5480884611579904


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

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