1408485 - Crash in m_free | m_freem | sctp_release_pr_sctp_chunk

Status: RESOLVED INCOMPLETE

(Core :: WebRTC: Networking, defect, P1)

Description

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

This bug was filed from the Socorro interface and is 
report bp-f86d2cfe-bf49-404e-94b8-839520171004.
=============================================================

UAF freeing buffers on a timeout -- may be the same as bug 1400563, or may be an independent bug.  It appears an e5e5 ptr was passed to m_free --  possible locking issue (or lack of locking)?

2 crashes in 57beta in the last month; 28 across all versions in the last week.

First crash may be in 44 (or earlier).

Comment 1

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

Michael - this is slightly different - same as the other bug, or a different cause?

Comment 2

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

Adding another signature that seems related - michael, please look at that signature too

Comment 3

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

The service_reassembly crash goes back to at least 43.0.1, may be older

Comment 4

[Michael Tüxen]

Not sure what happens. Possibly a double free? If I remember correctly, I fixed such bugs a while ago. Without being able to reproduce it, it is hard to say... The reassembly part has been substantially improved to support I-DATA using the same code path also for DATA chunks.

Comment 5

[Nils Ohlmeier [:drno]]

P1 because of UAF

Comment 6

[Daniel Veditz [:dveditz]]

Nils: please find an assignee for P1 bugs (or assign to a manager to do so. Picked you because you're "triage owner" for this component)

Comment 7

[Nils Ohlmeier [:drno]]

Lennart I believe you started already to take a look at this. Can I assign this to you?
Let me know if I should find someone else.

Comment 8

[Lennart Grahl [:lgrahl]]

Sorry, not really, this sounds like usrsctp internals and I wouldn't know where to look to be honest. But with Michael's comment I think it's reasonable to update the usrsctp code first and then see if it still happens.

Comment 9

[Nils Ohlmeier [:drno]]

As this is pretty hard to figure, but is pretty low frequency lets wait if the workaround landed in bug 1400563 changes anything for this bug.

Comment 10

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

Bug 1421963 may solve this

Comment 11

[Daniel Veditz [:dveditz]]

> Waiting to see if updating libsctp in bug 1297418 will fix this problem.

That landed in 59.

(In reply to Randell Jesup [:jesup] from comment #10)
> Bug 1421963 may solve this

Also landed in 59.

I'm not seeing crashes with this signature in 59 so I guess this is fixed?
Still lots of UAF crashes on ESR-52. Are either of those suitable for a back-port?

Comment 12

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

I think the sctp_service_reassembly crashes are fixed by bug 1421963.
The sctp_release_pr_sctp_chunk crashes appear to be the same issue as bug 1400563; with sctp timer firings triggering processing

Uplifting bug 1421963 may make a small help with ESR52, though note we also updated the entire library; it's always possible that eSR52 might react poorly (deadlocks) -- likely not, but it's not impossible.

Comment 13

[Nils Ohlmeier [:drno]]

I still see these two:
https://crash-stats.mozilla.com/report/index/b582d576-90f8-43b3-889e-2cb760180212
https://crash-stats.mozilla.com/report/index/f58ab31a-423c-4c8f-8692-184d30180208

in 59.0b6 and 59.0b7. Not sure what to make of them.

Comment 14

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

> I still see these two:

> in 59.0b6 and 59.0b7. Not sure what to make of them.

That's what I said in comment 12 - those appear to be a different symptom of the bug that causes bug 1400563 (probably a missing lock on timer_iterate's processing)

Uplifting the other patch to 52esr may fix the sctp_service_reassembly crashes

Comment 15

[Nils Ohlmeier [:drno]]

Interesting that there are so far no crash reports for 61 desktop at all.

Dan can I ask you to become the owner since I don't have cycles available.

Comment 16

[Dan Minor [:dminor]]

Transferring to Nico as it sounds like is taking over data channel work.

Comment 17

[Nils Ohlmeier [:drno]]

This might be fixed through bug 1521304, at least it appears to be related.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

60.9.0esr still has some reports with this signature, so maybe not fixed by bug 1521304. On the other hand, there are no reports from anything newer than that, so I don't think we need to leave this bug open anymore with ESR60 being EOL.

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit auto_nag documentation.