Open Bug 807738 Opened 7 years ago Updated 6 years ago

IPC parent aborts with malformed PHttpChannel::Msg_AsyncOpen

Categories

(Core :: IPC, defect, critical)

ARM
Gonk (Firefox OS)
defect
Not set
critical

Tracking

()

People

(Reporter: posidron, Assigned: cyu)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Attachments

(1 file)

[PHttpChannelChild] Sending Msg_AsyncOpen([TODO])
==> type int original value: 0 / now: -2147483648

An interception occurred only then if XRE_GetProcessType() equaled GeckoProcessType_Content.

Let me know if you need further information.
Attached file callstack
The stack trace indicates we're barfing on the parent, trying to read in the nsCString "entityID" in the PHttpChannel::RecvAsyncOpen message.   The code is trying to read in a bool indicating if the string is void or not, and it's asserting at 

  /ipc/chromium/src/base/pickle.cc:88
  
which indicates the bool field is neither 1 nor 0.  Most likely a serialization error where the 1/0 we wrote on child is somehow not the same bytes that the parent tries to read.  Unless we can somehow write an invalid field into the bool, which seem unlikely.

Do we have a reproducible case?  I'm guessing not, but it would be so helpful if we did...  Is there a URL where this fails with some regularity?

One idea here is to change the parameter order and see if we see a different crash--we might be able to winnow down which parameter is causing things to get out of whack.
Please note that this is an intentional fuzzing error, so the real problem here is that the deserialization routines abort instead of triggering the child to abort.
Invalid input from the content process should not cause the parent to abort, but unless we have evidence of this happening in the wild, this is a low-priority item.
Is there a test case for this?
I can take a look.
Assignee: nobody → cyu
Duplicate of this bug: 807263
Duplicate of this bug: 779988
You need to log in before you can comment on or make changes to this bug.