1739670 - Crash in [@ w2c_AffixMgr__process_pfx_in_order_PfxEntry___PfxEntry__], [@ w2c_AffixMgr__process_sfx_in_order_SfxEntry___SfxEntry__ ]

Status: RESOLVED FIXED

(Core :: Security: RLBox, defect)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

15 crashes from 8 installations of Firefox 95.0b3 as 32-bit version on Windows

Crash report: https://crash-stats.mozilla.org/report/index/c75d7fef-292b-4727-bfdd-f3bad0211105

Reason: EXCEPTION_STACK_OVERFLOW

Top 10 frames of crashing thread:

0 xul.dll w2c_AffixMgr__process_pfx_in_order_PfxEntry___PfxEntry__ security/rlbox/rlbox.wasm.c:56017
1 xul.dll w2c_AffixMgr__process_pfx_in_order_PfxEntry___PfxEntry__ security/rlbox/rlbox.wasm.c:56017
2 xul.dll w2c_AffixMgr__process_pfx_in_order_PfxEntry___PfxEntry__ security/rlbox/rlbox.wasm.c:56017
3 xul.dll w2c_AffixMgr__process_pfx_in_order_PfxEntry___PfxEntry__ security/rlbox/rlbox.wasm.c:56017
4 xul.dll w2c_AffixMgr__process_pfx_in_order_PfxEntry___PfxEntry__ security/rlbox/rlbox.wasm.c:56017
5 xul.dll w2c_AffixMgr__process_pfx_in_order_PfxEntry___PfxEntry__ security/rlbox/rlbox.wasm.c:56017
6 xul.dll w2c_AffixMgr__process_pfx_in_order_PfxEntry___PfxEntry__ security/rlbox/rlbox.wasm.c:56017
7 xul.dll w2c_AffixMgr__process_pfx_in_order_PfxEntry___PfxEntry__ security/rlbox/rlbox.wasm.c:56017
8 xul.dll w2c_AffixMgr__process_pfx_in_order_PfxEntry___PfxEntry__ security/rlbox/rlbox.wasm.c:56017
9 xul.dll w2c_AffixMgr__process_pfx_in_order_PfxEntry___PfxEntry__ security/rlbox/rlbox.wasm.c:56017

6 crashes from 2 installations for
Crash report: https://crash-stats.mozilla.org/report/index/25ab4b61-dff5-4af7-9dfe-1efab0211105

Reason: EXCEPTION_STACK_OVERFLOW

Top 10 frames of crashing thread:

0 xul.dll w2c_AffixMgr__process_sfx_in_order_SfxEntry___SfxEntry__ security/rlbox/rlbox.wasm.c:56031
1 xul.dll w2c_AffixMgr__process_sfx_in_order_SfxEntry___SfxEntry__ security/rlbox/rlbox.wasm.c:56048
2 xul.dll w2c_AffixMgr__process_sfx_in_order_SfxEntry___SfxEntry__ security/rlbox/rlbox.wasm.c:56048
3 xul.dll w2c_AffixMgr__process_sfx_in_order_SfxEntry___SfxEntry__ security/rlbox/rlbox.wasm.c:56048
4 xul.dll w2c_AffixMgr__process_sfx_in_order_SfxEntry___SfxEntry__ security/rlbox/rlbox.wasm.c:56048
5 xul.dll w2c_AffixMgr__process_sfx_in_order_SfxEntry___SfxEntry__ security/rlbox/rlbox.wasm.c:56048
6 xul.dll w2c_AffixMgr__process_sfx_in_order_SfxEntry___SfxEntry__ security/rlbox/rlbox.wasm.c:56048
7 xul.dll w2c_AffixMgr__process_sfx_in_order_SfxEntry___SfxEntry__ security/rlbox/rlbox.wasm.c:56048
8 xul.dll w2c_AffixMgr__process_sfx_in_order_SfxEntry___SfxEntry__ security/rlbox/rlbox.wasm.c:56048
9 xul.dll w2c_AffixMgr__process_sfx_in_order_SfxEntry___SfxEntry__ security/rlbox/rlbox.wasm.c:56048

Comment 1

[Pascal Chevrel:pascalc]

Fixed in beta by backout.

Comment 2

[Shravan Narayan]

Investigating this now.

Comment 3

[Dianna Smith [:diannaS]]

Any update on this? We are approaching the end of the 96 nightly cycle.

Comment 4

[Shravan Narayan]

@diannaS: Sorry for the delay. i had posted an update on a different bug thread that was modifying the same hunspell spellchecking component and forgot to post here. So the investigations led us to believe that this was another presentation of Bug 1739669 whose patch was pushed to nightly and rolled up to beta a little while back.

However, I see that there is one instance of this crash report last week --- which is confusing in a couple of ways

• If this is another presentation of Bug 1739669, then we shouldn't be seeing crashes
• Given that we are seeing a crash, why are we seeing it only one or two reports

@bholley - what do you think the best way to proceed here would be? Given the low incident count, my thinking is that we wait to see if we see more cases once this lands on stable. Does this make sense to you?

If we assume that this behavior is a due to a separate bug which we would need to investigate, here is what we know so far

• the only way this could happen is if the sandboxed hunspell code has a memory corruption of some kind (the rlbox sandboxing would prevent this from being a vulnerability though).
• Given that this bug happens on 32 bit and not 64 bit, this must be a part of it. On 64-bit systems, rlbox sandboxing uses 4gb mem with 4gb guard pages. On 32 bit we use 16mb memory and mask memory access back into the memory, so an OOB would arbitrarily access/modify some random sandbox memory.

One way to collect more information on this bug would be

• Add a function depth count in sandbox hunspell code and trap if we cross the limit
• Add a sandbox_invoke_or_fail method to RLBox that would use setjmp and longjmp to recover from wasm traps
• Modify hunspell calls in Firefox to use the above RLBox API on the potentially recursive call. If we encounter a failure, just gracefully return from the spell checker
• Add some telemetry to capture if these silent hunspell failures are occuring to users

Comment 5

[Bobby Holley (:bholley)]

That one crash report is from 95b3. Very confident this is fixed by bug 1739669.