New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 797865 link

Starred by 2 users
Status: Untriaged
Owner: ----
Cc:
kkaluri@chromium.org
tue...@fh-muenster.de
█ emadomara@chromium.org
webrtc-network-bugs@google.com
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Data race in sctp_med_chunk_output

Project Member Reported by ClusterFuzz, Dec 28 2017 
Detailed report: https://clusterfuzz.com/testcase?key=5712062662836224

Fuzzer: inferno_twister
Job Type: linux_tsan_chrome_mp
Platform Id: linux

Crash Type: Data race READ 4
Crash Address: 0x7b5400091148
Crash State:
  sctp_med_chunk_output
  sctp_chunk_output
  sctp_common_input_processing
  
Sanitizer: thread (TSAN)

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

Issue filed automatically.

See https://github.com/google/clusterfuzz-tools for more information.

Comment 1 by kkaluri@chromium.org, Dec 28 2017

Cc: tue...@fh-muenster.de kkaluri@chromium.org
Components: Internals>Network>Library
Labels: M-64 CF-NeedsTriage
Predator and CL could not provide any possible suspects.
Using Code Search for the file, "sctp_output.c" assigning to the concern owner who might be related.

Since author is not a chromium member, cc'ing him and untriaging this issue
 
tuexen@ -- Could you please look into the issue, kindly re-assign if this is not related to your changes.


Thank You.

Comment 2 by pauljensen@chromium.org, Jan 2 2018

Components: -Internals>Network>Library Blink>WebRTC
The clusterfuzz.com link doesn't seem to load, but usrsctp looks only used from WebRTC.

Comment 3 by guidou@chromium.org, Jan 8 2018

Components: -Blink>WebRTC Blink>WebRTC>Network

Comment 4 by tue...@fh-muenster.de, Jan 8 2018 

I have no access to the detailed report, so I can't do anything related to this bug.

Best regards
Michael

Comment 5 by deadbeef@webrtc.org, Jan 8 2018 

Here's the relevant information:

WARNING: ThreadSanitizer: data race (pid=20025)
Write of size 4 at 0x7b5400091148 by thread T28 (mutexes: write M17130):
#0 0x7f1dc170b137 in user_sctp_timer_iterate third_party/usrsctp/usrsctplib/usrsctplib/netinet/sctp_callout.c:164:15
Previous read of size 4 at 0x7b5400091148 by thread T14 (mutexes: write M17147):
 #0 0x7f1dc16ec807 in sctp_med_chunk_output third_party/usrsctp/usrsctplib/usrsctplib/netinet/sctp_output.c:9312:23
 #1 0x7f1dc16e5c86 in sctp_chunk_output third_party/usrsctp/usrsctplib/usrsctplib/netinet/sctp_output.c:10689:11
 #2 0x7f1dc16fc9f5 in sctp_common_input_processing third_party/usrsctp/usrsctplib/usrsctplib/netinet/sctp_input.c:6097:3
#3 0x7f1dc1690191 in usrsctp_conninput third_party/usrsctp/usrsctplib/usrsctplib/user_socket.c:3490:2

So, it's a race between sctp_handle_tick writing to c_flags here:

  c->c_flags &= ~SCTP_CALLOUT_PENDING;

And sctp_med_check_output reading it here:

  if (bundle_at && (!SCTP_OS_TIMER_PENDING(&net->rxt_timer.timer))) {

Comment 6 by anatolid@chromium.org, Feb 9 2018

Labels: Needs-Feedback
@tuexen could you please provide feedback on #8?

Comment 7 by tue...@fh-muenster.de, Feb 9 2018 

Yes, it is not critical. Just thinking about a good way to fix it...
Sorry for the delay.

Best regards
Michael
►

Sign in to add a comment