Created attachment 634753 [details] testcase (crashes Firefox when loaded) Loading the testcase makes Firefox crash [@ OpenTypeReorderingOutput::getStringIndex ] For Mac OS X 10.7.4 (11E53), this appears as [@ CoreText@0x837b4 ] (bp-53a19b57-4ff8-4617-8835-b68db2120620)
Created attachment 634808 [details] modified testcase, also crashes Safari This is an Apple bug (within Core Text); here's a version of the testcase that crashes similarly (slightly different stack) in Safari on 10.7.
(The original testcase didn't crash Safari, at least for me, because it happens to pick a different fallback font for the Kannada characters when no suitable font has been explicitly chosen.)
I've filed bug 766505 to update the Mac font prefs so that we'll use the AAT fonts shipped with current versions of OS X where possible. This prevents the crash with the original testcase, as we no longer fall back to Arial Unicode MS, and in general it will make this issue much less likely to show up. Note that it doesn't really resolve the problem, though, because a page (like the second testcase) that explicitly chooses Arial Unicode MS (or, probably, other OpenType Kannada fonts) will still hit the Core Text bug here.
Filed rdar://11707231 to report this to Apple.
Thanks for investigating and for marking the bug as security-sensitive. The Safari crash is at null 2/3 of the time, but a random-looking address 1/3 of the time.
Jonathan, did you get any response from Apple in rdar://11707231 ?
Apple says: "We believe this issue has been addressed in OS X Mountain Lion 10.8, and there are no plans to backport the fix to OS X 10.7.x." I haven't tested this myself yet, as I'm still running 10.7 here. Do you have a 10.8 system to verify this? Or maybe Jesse could do so. Note that since bug 797402, landed for FF19, we're no longer likely to run into this issue, as we shape Indic OpenType fonts using HarfBuzz instead of Core Text. (Setting gfx.font_rendering.harfbuzz.scripts back to zero would force the use of the Core Text path in all cases, for testing purposes.)
Great, thanks. I'm also on 10.7 so I can't verify Apple has fixed it in 10.8. I can confirm FF18 crashes, and that FF19 does not crash (with default prefs). So can we resolve this bug since bug 797402 mitigates it (for all OSX versions) in FF19 and later with default prefs?
Depends on: 797402
Seems reasonable. Resolving as FIXED, even though for 10.7, it's fixed by changing our default prefs so as to avoid the problem code (in OS X) rather than fixing the underlying problem. Note that FF18 remains vulnerable to this on OS X 10.7. Nothing we can do about that, really, unless we were to disable Indic OpenType shaping altogether for users of that version. But I don't think that's worth pursuing, with a fix already on the way in FF19. Marking tracking-esr17? to bring this to esr drivers' notice; presumably esr17 remains vulnerable to this, as it would use the Core Text path for such fonts. I think we have three options there: (a) Do nothing; accept that esr17 on OS X 10.7 may be vulnerable to this crash. (b) Backport a harfbuzz update to support Indic shaping (I guess we'd want at least bug 789687, though if we're going to backport the library update, maybe we should go all the way to the current release), and then take the pref change from bug 797402 on esr17 as well; that would be the "proper" fix. (c) Just take the pref change from bug 797402 on esr17, without updating harfbuzz. This would avoid the potential crash on 10.7, but would break shaping of Indic OpenType fonts for OS X users. Personally, I'd lean towards (a), as I think (b) is too big a code change for ESR to justify for this issue, and (c) makes for a very negative user experience. (OK, crashing would also be a very negative experience, but I'm not aware of any indication that this is a widespread issue in the wild.) But over to ESR drivers here...
Status: NEW → RESOLVED
Last Resolved: 5 years ago
status-firefox18: --- → affected
status-firefox19: --- → fixed
status-firefox20: --- → fixed
status-firefox21: --- → fixed
status-firefox-esr17: --- → affected
tracking-firefox-esr17: --- → ?
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
status-b2g18: --- → unaffected
status-firefox-esr17: affected → wontfix
tracking-firefox-esr17: ? → -
Alex says the potential usability regression in (c) is too big for an ESR, even if we doubt very many macs are used in enterprises in the India region. Wontfixing for ESR-17
Whiteboard: [rdar://11707231] → [rdar://11707231][adv-main19+]
You need to log in before you can comment on or make changes to this bug.