Closed
Bug 1349903
Opened 8 years ago
Closed 8 years ago
HttpChannelParent::DoAsyncOpen() would crash when a void LoadInfo is received
Categories
(Core :: Networking: HTTP, enhancement)
Core
Networking: HTTP
Tracking
()
RESOLVED
FIXED
mozilla55
| Tracking | Status | |
|---|---|---|
| firefox55 | --- | fixed |
People
(Reporter: hchang, Assigned: timhuang)
References
Details
(Whiteboard: [necko-active])
Attachments
(2 files)
Since |LoadInfoArgsToLoadInfo| might return NS_OK with a null output loadInfo [1], the |loadInfo| access below [2] needs a nullity check.
[1] http://searchfox.org/mozilla-central/rev/9af9b1c7946ebef6056d2ee4c368d496395cf1c8/ipc/glue/BackgroundUtils.cpp#359
[2] http://searchfox.org/mozilla-central/rev/9af9b1c7946ebef6056d2ee4c368d496395cf1c8/netwerk/protocol/http/HttpChannelParent.cpp#365
Tim, is looks like you did the HttpChannelParent.cpp change, you up to addressing this concern?
Flags: needinfo?(tihuang)
| Reporter | ||
Comment 2•8 years ago
|
||
I am also aware the originAttributes we get from loadInfo is not used at all.
That part can be removed. The rest of concern is when we get a null loadInfo,
should we return error or pass it around. (loadInfo will be used to new the
actual channel a couple of lines below.)
| Assignee | ||
Comment 3•8 years ago
|
||
The original purpose of the originAttributes here is for appId. However, the appId is gone. So I think we can remove this part of code. And I think we should return an error when we get a null loadInfo since every channel should have a loadInfo.
Assignee: nobody → tihuang
Status: NEW → ASSIGNED
Flags: needinfo?(tihuang)
| Comment hidden (mozreview-request) |
Comment 5•8 years ago
|
||
originAttributes is heavily used by tor for segmenting things by first party.. does that apply here?
Comment 6•8 years ago
|
||
| mozreview-review | ||
Comment on attachment 8851161 [details]
Bug 1349903 - Remove the code section of getting originAttributes from loadInfo in HttpChannelParent::DoAsyncOpen() and add a null check for loadInfo.
https://reviewboard.mozilla.org/r/123542/#review126264
has there been a test case for this? seems like this has been reported w/o a crash report based only on code inspection
Attachment #8851161 -
Flags: review?(honzab.moz) → review+
| Reporter | ||
Comment 7•8 years ago
|
||
I spotted this issue when I was initiating the IPDL-based fuzzing work.
As a starter/exploration/experiment, I picked some typical protocols to handicraft
their fuzzer. Compared to low level IPC fuzzing, the intention of IPDL fuzzing is to
be able to assemble more parameter-type-aware IPC message so that we can try to
attack the "handler" level instead of merely the IPC infrastructure.
Since PHttpChannel is so frequently used and is managed by PNecko/PContent (which
is the most fundamental parent protocols), it's chosen as my very first fuzzer.
| Assignee | ||
Comment 8•8 years ago
|
||
Keywords: checkin-needed
Comment 9•8 years ago
|
||
need final review/ship it on mozreview so that we can use the autoland feature.
Flags: needinfo?(tihuang)
Updated•8 years ago
|
Keywords: checkin-needed
| Assignee | ||
Comment 11•8 years ago
|
||
Carrying r+ from Honza. Please land this patch instead of the patch from
mozreivew. Thanks a lot.
Attachment #8852344 -
Flags: review+
| Assignee | ||
Updated•8 years ago
|
Flags: needinfo?(tihuang)
Keywords: checkin-needed
| Assignee | ||
Comment 12•8 years ago
|
||
Sheriff, could you please land the patch from comment 11 to inbound. Thanks a lot.
Comment 13•8 years ago
|
||
Pushed by ihsiao@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/bef7c269687e
Remove the code section of getting originAttributes from loadInfo in HttpChannelParent::DoAsyncOpen() and add a null check for loadInfo. r=mayhemer
Keywords: checkin-needed
Comment 14•8 years ago
|
||
| bugherder | ||
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox55:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
You need to log in
before you can comment on or make changes to this bug.
Description
•