NULL deref crash in m_copydata

[taylor-b]

We are seeing another crash even after updating usrsctp to revision bee946a.

It's similar to #351 and #382, except this time stemming from usrsctp_sendv rather than usrsctp_conninput.

#6  m_copydata (m=0x0, off=0, len=530, cp=0xc77f2963048 "") at third_party/usrsctp/usrsctplib/user_mbuf.c:1394
#7  sctp_copy_mbufchain (clonechain=<optimized out>, outchain=0xc775b838700, endofchain=0x7fe96e7c3c38, can_take_mbuf=<optimized out>, sizeofcpy=<optimized out>, copy_by_ref=<optimized out>) at third_party/usrsctp/usrsctplib/netinet/sctp_output.c:7029
#8  0x0000558a2fa3558e in sctp_med_chunk_output (inp=<optimized out>, stcb=<optimized out>, asoc=<optimized out>, num_out=0x7fe96e7c3d94, reason_code=0x7fe96e7c3d84, control_only=<optimized out>, from_where=0, now=0x7fe96e7c3d50, now_filled=0x7fe96e7c3d90, frag_point=1184, so_locked=1)
    at third_party/usrsctp/usrsctplib/netinet/sctp_output.c:9260
#9  0x0000558a2fa32033 in sctp_chunk_output (inp=0xc7744d3d600, stcb=0xc77b7688400, from_where=0, so_locked=1) at third_party/usrsctp/usrsctplib/netinet/sctp_output.c:10729
#10 0x0000558a2fa0ba16 in sctp_lower_sosend (so=<optimized out>, addr=<optimized out>, uio=<optimized out>, i_pak=<optimized out>, control=0x0, flags=<optimized out>, srcv=<optimized out>) at third_party/usrsctp/usrsctplib/netinet/sctp_output.c:14811
#11 0x0000558a2fa09df6 in usrsctp_sendv (so=0xc77baa3b680, data=<optimized out>, len=768, to=0x0, addrcnt=<optimized out>, info=<optimized out>, infolen=32, infotype=4, flags=0) at third_party/usrsctp/usrsctplib/user_socket.c:943

Also, we're seeing this in the wild rather than with a fuzzer, so we don't have a way to reproduce. Are you aware of any issue like this?

[tuexen]

I would love to have a way to reproduce it... If I remember it correctly, the problem must be earlier, the backtrace just shows where the earlier bug manifests in a NULL pointer dereference.

[markwo]

I wonder if this is the same root-cause as #160 (comment) ?

In the crashing code we're not using SCTP_PR_SCTP_PRIO, but are using SCTP_PR_SCTP_RTX.
I suspect SCTP-PR is required to hit the issue, along with some random packet loss. (I'll try a stress test that does this and let you know if I get a reliable repro).

The code calling sendv() is :

  struct sctp_sendv_spa spa = {0};
  spa.sendv_flags |= SCTP_SEND_SNDINFO_VALID;
  spa.sendv_sndinfo.snd_sid = message.stream_id();
  spa.sendv_sndinfo.snd_ppid = htonl(message.ppid());

  spa.sendv_sndinfo.snd_flags |= SCTP_UNORDERED;
  spa.sendv_flags |= SCTP_SEND_PRINFO_VALID;
  spa.sendv_prinfo.pr_policy = SCTP_PR_SCTP_RTX;
  spa.sendv_prinfo.pr_value = 1;  // number of retransmits.

[tuexen]

I wouldn't assume people are using SCTP_PR_SCTP_PRIO. I think they are using SCTP_PR_SCTP_RTX or SCTP_PR_SCTP_TTL. So your guess might be correct. Please let me know if you find a way to reproduce that. I think I reviewed the code in the past for a bug in the PR-SCTP code, but couldn't find it by code inspection. So a reproducer would be very handy.