1791296 - UAF in sctp_reset_clear_pending in TSAN run of web-platform test webrtc/RTCDataChannel-close.html

Status: RESOLVED FIXED

(Core :: WebRTC: Networking, defect)

Description

[Randell Jesup [:jesup] (needinfo me)]

UAF in sctp_reset_clear_pending during a TSAN run. No patches that should affect this. The only change that even theoretically could affect it was reversing the list of cleanup in the testharness.js for wpt tests.

It was freed when we called SendOutgoingStreamReset() which did a usrsctp_setsockopt() which ended up freeing this data.

It's not a race between conninput() and the setsockopt(), since both were called on the same thread.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Attachment: uaf

Comment 2

[Jim Mathies [:jimm]]

This may be solved by switching to Google's new lib once they feel confident about shipping it. TBD on level of effort to integrate with that. We'll figure that in in Q4.

Comment 3

[Maire Reavy [:mreavy]]

Hey Byron -- Is this likely to be addressed by the sctp library update? If not, is there anything we can investigate here, or is this stalled? Thanks!

Comment 4

[Jim Mathies [:jimm]]

Closing this out, please file a new bug if we see it again.

Comment 5

[Tom Ritter [:tjr]]

Advisory will go in Bug 1795697

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Bug 1795697 grafts cleanly to ESR102. Given that it was rated sec-high, should we consider doing the backport still? It'd be too late for 102.6esr at this point, but we could possibly do so for 102.7.

Comment 7

[Byron Campen [:bwc]]

Let me run some tests; this code is a bit deadlock-prone.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

FYI, we're not going to be able to get this backported to ESR in time for next week's release, but we're aiming to do so for 102.7.

Comment 9

[Tom Ritter [:tjr]]

sgtm

Comment 10

[June Wilde (she/her) [:jewilde]]

Advisory for 102.7 ESR uplift will also go in 1795697 and reuse the advisory Tom wrote there