933825 - IPC: crash with PContentPermissionRequest::Msg_prompt [@nsContentPermissionRequestProxy::GetPrincipal]

Status: RESOLVED INCOMPLETE

(Core :: DOM: Content Processes, defect, P5)

Description

[Christoph Diehl [:posidron]]

Attachment: fuzzing-session

Tested with an opt/non-debug build of https://github.com/posidron/mozilla-central/commit/26121cb

Comment 1

[Andrew McCreight [:mccr8]]

doug, is there somebody who can look at this?

Comment 2

[Daniel Veditz [:dveditz]]

Are faulty sessions replayable? It would help fixing these bugs if devs can catch the problem in a debugger. Maybe we need a post-processing step that pulls out the message traffic, and then a way to feed those changes back into faulty or a stub process.

Comment 3

[Christoph Diehl [:posidron]]

They are to a certain degree - if you provide the seed during the launch and perform the same actions on the device there is high likelihood to reproduce the same crash.

I want to run in the next days mochitests and/or crashtests on the device, this should create more reliable and reproducible cases because each test would represent a pre-defined action to trigger messages.

Note, that the updated version of Faulty has a much better logging mechanism and the logs look much cleaner than of the version used here for this crash.

The other approach which would be interesting is to hook into Channel::ChannelImpl::ProcessOutgoingMessages() which would give us the ability to filter messages and fuzz only specific messages. Though, we would loose the ability to smart-fuzz the pickle types.

Comment 4

[Doug Turner (:dougt)]

Cdiehl,

Could you try again with the patch:
    https://bug927521.bugzilla.mozilla.org/attachment.cgi?id=823173

Comment 5

[Christoph Diehl [:posidron]]

Sorry for the delay - had no internet this week. I will re-test with the patch as soon as possible.

Comment 6

[Christoph Diehl [:posidron]]

Have reproduced the crash with the patch applied by repeatedly flipping the state for GeoLocation and Airplane mode to 'on' and 'off'.

During that time the fuzzer made a change in the Msg_PContentPermissionRequestConstructor message.

I/Gecko   (10822): [Faulty] pickle field {bool} of value: 0 changed to: 1
I/Gecko   (10822): [Faulty] - sendmsg() - message @0xb2809040 with name PBrowser::Msg_PContentPermissionRequestConstructor on channel @0xb4a52000 type=524318 transaction_id=-1 routing_id=2 seq_no=0

The following messages were not modified and followed right after the above message:

I/Gecko   (10822): [Faulty] - sendmsg() - message @0xb2809040 with name PContentPermissionRequest::Msg_prompt on channel @0xb4a52000 type=1310721 transaction_id=-1 routing_id=-28 seq_no=0
I/Gecko   (10822): [Faulty] - sendmsg() - message @0xb2809040 with name PBrowser::Msg_PContentPermissionRequestConstructor on channel @0xb4a52000 type=524318 transaction_id=-1 routing_id=2 seq_no=0
I/Gecko   (10822): [Faulty] - sendmsg() - message @0xb2809040 with name PContentPermissionRequest::Msg_prompt on channel @0xb4a52000 type=1310721 transaction_id=-1 routing_id=-29 seq_no=0
I/Gecko   (10822): [Faulty] - sendmsg() - message @0xb2809080 with name PBrowser::Msg_PContentPermissionRequestConstructor on channel @0xb4a52000 type=524318 transaction_id=-1 routing_id=2 seq_no=0
I/Gecko   (10822): [Faulty] - sendmsg() - message @0xb2809080 with name PContentPermissionRequest::Msg_prompt on channel @0xb4a52000 type=1310721 transaction_id=-1 routing_id=-30 seq_no=0

I/Gecko   (10822): [Faulty] - sendmsg() - message @0xb20715a0 with name PIndexedDBTransaction::Msg_AllRequestsFinished on channel @0xb4a52000 type=3932166 transaction_id=-1 routing_id=-20 seq_no=0
I/Gecko   (10822): [Faulty] - sendmsg() - message @0xb2e0a520 with name PIndexedDBDatabase::Msg_PIndexedDBTransactionConstructor on channel @0xb4a52000 type=3145737 transaction_id=-1 routing_id=-10 seq_no=0
I/Gecko   (10822): [Faulty] - sendmsg() - message @0xb2e0a520 with name PIndexedDBTransaction::Msg_PIndexedDBObjectStoreConstructor on channel @0xb4a52000 type=3932163 transaction_id=-1 routing_id=-31 seq_no=0
I/Gecko   (10822): [Faulty] - sendmsg() - message @0xb36fd7c0 with name PIndexedDBObjectStore::Msg_PIndexedDBRequestConstructor on channel @0xb4a52000 type=3670021 transaction_id=-1 routing_id=-32 seq_no=0
I/Gecko   (10822): [Faulty] - sendmsg() - message @0xb20df100 with name PBluetooth::Msg_PBluetoothRequestConstructor on channel @0xb4a52000 type=262154 transaction_id=-1 routing_id=-19 seq_no=0
I/Gecko   (10822): [Faulty] - sendmsg() - message @0xb20df160 with name PContent::Msg_AsyncMessage on channel @0xb4a52000 type=1179771 transaction_id=-1 routing_id=2147483647 seq_no=0
I/Gecko   (10822): [Faulty] - sendmsg() - message @0xb20df320 with name PLayerTransaction::Msg_Update on channel @0xb3d8b000 type=4325383 transaction_id=-1 routing_id=-1 seq_no=-9

[Crash]

Comment 7

[Christoph Diehl [:posidron]]

Attachment: fuzzing-session-with-patch-823173

Comment 8

[Andrew McCreight [:mccr8]]

Ben, could you look at this or figure out somebody else who could look at it?  Thanks.

Comment 9

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Hm, I'm not sure what this bug is about really...

The original report (attachment 825981 [details]) looks like we're not expecting the child to ever send a null principal along with a permission request. The fuzzer has cleverly switched the "do I have a principal" flag from true to false and then we're trying to addref a null pointer. This needs to be made more robust.

Attachment 8340650 [details] looks like a totally separate child process crash (and I'd argue that it's not a bug anyway).

Comment 10

[Ben Turner (not reading bugmail, use the needinfo flag!)]

(In reply to ben turner [:bent] (use the needinfo? flag!) from comment #9)
> the "do I have a principal" flag from true to false

It's actually the "is my principal null" flag, and it's being switched from false to true.

Comment 11

[Andrew McCreight [:mccr8]]

If this is just an addref of a null pointer, it doesn't sound that bad.

Comment 12

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.

Comment 13

[Andrei Purice]

Hey Daniel,
Does this issue still reproduce for you or can it be closed?

Comment 14

[Andrew McCreight [:mccr8]]

I think we can close B2G-era IPC fuzz bugs.