Closed
Bug 1270328
Opened 9 years ago
Closed 9 years ago
Use-after-forget in WebSocketChannel::ProcessInput
Categories
(Core :: Networking: WebSockets, defect)
Core
Networking: WebSockets
Tracking
()
RESOLVED
FIXED
mozilla49
| Tracking | Status | |
|---|---|---|
| firefox49 | --- | fixed |
People
(Reporter: jld, Assigned: jld)
References
Details
(Whiteboard: [necko-active])
Attachments
(1 file)
|
1.02 KB,
patch
|
mcmanus
:
review+
|
Details | Diff | Splinter Review |
The static analysis in bug 1186706 points out that WebSocketChannel::ProcessInput can use the value of a RefPtr after forget() is called on it, because of this:
1757 if (frame) {
1758 // We send the frame immediately becuase we want to have it dispatched
1759 // before the CallOnServerClose.
1760 mService->FrameReceived(mSerial, mInnerWindowID, frame.forget());
1761 }
And this:
1798 if (frame) {
1799 mService->FrameReceived(mSerial, mInnerWindowID, frame.forget());
1800 }
This looks harmless in practice because the first forget() sets the pointer to null, but the analysis treats it like Move(), as being invalid to access — and I tend to agree that it would be clearer to have an explicit `frame = nullptr;` there if something is going to depend on that.
| Assignee | ||
Comment 1•9 years ago
|
||
Attachment #8748974 -
Flags: review?(mcmanus)
Comment 2•9 years ago
|
||
Comment on attachment 8748974 [details] [diff] [review]
bug1270328-websocket-frame-hg0.diff
Review of attachment 8748974 [details] [diff] [review]:
-----------------------------------------------------------------
any chance of teaching the analysis tool the semantics of forget? I doubt this is the only place.
Attachment #8748974 -
Flags: review?(mcmanus) → review+
Updated•9 years ago
|
Whiteboard: [necko-active]
| Assignee | ||
Comment 3•9 years ago
|
||
(In reply to Patrick McManus [:mcmanus] from comment #2)
> any chance of teaching the analysis tool the semantics of forget? I doubt
> this is the only place.
It seems to be the only place — there were two regressions that turned up when I tried to dust off bug 1186706 to test bug 1191452, and the other one looks like it actually would dereference a null pointer (but only if the right non-default logging option is set).
| Assignee | ||
Updated•9 years ago
|
Keywords: checkin-needed
Keywords: checkin-needed
Comment 5•9 years ago
|
||
| bugherder | ||
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
You need to log in
before you can comment on or make changes to this bug.
Description
•