Assuming that this code runs in the renderer -- please correct me if I'm wrong.

Also assuming this impacts stable.

I have a trivial PR waiting to be merged, to fix crbug.com/811477, so we might as well wait for that before rolling usrsctp (meaning updating DEPS).

Do we need to merge this to M68 too (and M67)? Adding merge request labels so someone can answer that.

If so I assume we'd only want to merge the individual commit, and would need to use an "overrides" directory containing the two modified files?

This bug requires manual review: Less than 28 days to go before AppStore submit on M68
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

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

+awhalley@ (Security TPM) for merge review

Please mark security bugs as fixed as soon as the fix lands, and before requesting merges. This update is based on the merge- labels applied to this issue. Please reopen if this update was incorrect.

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

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

commit 462adb280cda73411873a4a0963ce5548759bd9f
Author: Taylor Brandstetter <deadbeef@chromium.org>
Date: Mon Jun 25 18:56:57 2018

Roll src/third_party/usrsctp/usrsctplib/ 159d060dc..7a8bc9a90 (35 commits)

Fixes a buffer overflow bug (see bug link below).

https://chromium.googlesource.com/external/github.com/sctplab/usrsctp/+log/159d060dceec..7a8bc9a90ca9

$ git log 159d060dc..7a8bc9a90 --date=short --no-merges --format='%ad %ae %s'
2018-06-22 deadbeef Switching from localtime to localtime_r on non-Windows platforms.
2018-06-14 tuexen Ensure that the ip6_plen is provided in network byte order.
2018-06-06 tuexen Improve compliance with RFC 4895 and RFC 6458.
2018-06-02 tuexen Don't overflow a buffer if we receive an INIT or INIT-ACK chunk without a RANDOM parameter but with a CHUNKS or HMAC-ALGO parameter. Please note that sending this combination violates the specification.
2018-05-29 tuexen Try to please the Windows compiler.
2018-05-29 tuexen Plug memory leak recently introduced.
2018-05-28 weinrank Suppress 'type-limits' warning for GCC
2018-05-28 tuexen Fix mask.
2018-05-26 tuexen Allow sys tunables to be set before calling usrsctp_init().
2018-05-26 tuexen Add range check for sysctl set functions.
2018-05-21 tuexen Fix typo.
2018-05-21 tuexen Cleanup and sync with FreeBSD sources.
2018-05-21 tuexen Backport https://svnweb.freebsd.org/changeset/base/333813.
2018-05-21 tuexen Whitespace change.
2018-05-14 tuexen Sync FreeBSD ID and minor cleanups.
2018-05-14 tuexen Ensure MTUs are a multiple of 4.
2018-05-14 ruengeler m_last is not needed
2018-05-09 ruengeler Build clusters
2018-05-09 ruengeler Set DF Flag correctly
2018-05-08 tuexen Remove stray =.
2018-05-08 tuexen Don't invalidate the sockets, since even they are closed, the value is used to join the corresponding threads.
2018-05-08 tuexen Fix typos.
2018-05-08 tuexen When reporting ERROR or ABORT chunks, don't use more data that is guaranteed to be contigous. Thanks to Felix Weinrank for finding and reporting this bug by fuzzing the usrsctp stack.
2018-05-08 tuexen sctp_get_mbuf_for_msg() should return NULL if mbuf is too small.
2018-05-06 tuexen Don't dereference a NULL pointer.
2018-05-06 tuexen Handle the case of m == NULL in m_copym().
2018-04-26 justin.kim recv_thread: Invalidate socket after closing
2018-04-08 tuexen Fix logical inversion bug.
2018-04-08 tuexen Small cleanup, no functional change.
2018-04-08 tuexen Fix a signed/unsiged warning.
2018-03-27 deadbeef Fix increment in sctp_connectx_helper_add
2018-03-27 deadbeef Fix cast in sctp_findassociation_ep_addr
2018-03-23 weinrank Fix warnings for "atomic_init"
2018-03-23 weinrank Check for "-Wstrict-prototypes"
2018-03-21 tuexen Use HTTP/SCTP PPID.

Created with:
  roll-dep src/third_party/usrsctp/usrsctplib

Bug:  chromium:854883 , chromium:811477
Change-Id: Ib3db2407c2e591b4162c675596346d8be00955a6
Reviewed-on: https://chromium-review.googlesource.com/1112590
Reviewed-by: Henrik Boström <hbos@chromium.org>
Commit-Queue: Taylor Brandstetter <deadbeef@chromium.org>
Cr-Commit-Position: refs/heads/master@{#570114}
[modify] https://crrev.com/462adb280cda73411873a4a0963ce5548759bd9f/DEPS
[modify] https://crrev.com/462adb280cda73411873a4a0963ce5548759bd9f/third_party/usrsctp/README.chromium

Seems like this just landed yesterday. Can you please confirm if this verified in canary yet? Is this absolutely critical for M68, and overall a safe merge?

It's shipped in Canary 69.0.3473.0 (chromiumdash.appspot.com is helpful for this); it hasn't technically been "verified" as that would require an SCTP implementation that violates the standard, but it's pretty safe to assume the issue is fixed just by looking at the code.

The commit which we'd merge is https://github.com/sctplab/usrsctp/commit/8789a6da02e2c7c03522bc6f275b302f6ef977fe. All it does is set a variable to "0" which would otherwise be undefined, so it's completely safe.

As for whether it's "critical for M68", I was hoping you could tell me. What's the general policy on security bugs of this nature?

Approving merge to M68.Branch:3440

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

We're not planning any further M67 releases. Pls target fix for M68.

Can you please go ahead and merge this to 68? it's approved.

Emad, can you find another owner? Also, can anyone confirm whether or not the preferred approach in this scenario (merging a fix from a third party library) is patching the individual commit via an "overrides" directory, or is there a simpler way?

any update on this?

 awhalley@ This will most likely miss M68 if not merged today by 4PM.

Maybe the below link can help with the merge. Assigning to deadbeef@chromium.org since emadomara@chromium.org account says "user never visited." deadbeef@ can you possibly help with this since I also see emadomara@ is on work travel.

https://www.chromium.org/developers/how-tos/drover

I don't work at Google any more, but this is something anyone could do

Please merge your change to M69 branch 3497 by 4:00 PM PT today, so we can pick it up for next week LAST M69 Dev release before Beta promotion. Thank you.

+hbos@/tommi@, could anyonf of you pls merge the change to M69 branch 3497?

Please merge your change to M69 branch 3497 by 2:00 PM PT Monday, 07/30, so we can pick it up for next week last M69 Dev release. Thank you.

Per steveanton@, commit already landed in M69 (it was merged before the cut): https://storage.googleapis.com/chromium-find-releases-static/462.html#462adb280cda73411873a4a0963ce5548759bd9f. No merge needed.

Removing "Merge-Approved-69" label. Thank you.

Thank you!

This bug has been closed for more than 14 weeks. Removing security view restrictions.

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