AddressSanitizer: heap-use-after-free on nsLineBreaker::FlushCurrentWord() after malloc failure
Categories
(Core :: Layout: Text and Fonts, defect, P2)
Tracking
()
People
(Reporter: sourc7, Assigned: jfkthame)
Details
(Keywords: csectype-uaf, reporter-external, sec-moderate, Whiteboard: [client-bounty-form][adv-main134+][adv-ESR128.6+][adv-ESR115.19+])
Attachments
(13 files)
9.15 KB,
text/plain
|
Details | |
9.15 KB,
text/plain
|
Details | |
9.31 KB,
text/plain
|
Details | |
738 bytes,
patch
|
Details | Diff | Splinter Review | |
425 bytes,
text/html
|
Details | |
22.29 KB,
text/plain
|
Details | |
20.36 KB,
text/plain
|
Details | |
6.08 KB,
text/plain
|
Details | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-beta+
|
Details | Review |
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-esr128+
|
Details | Review |
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-esr115+
|
Details | Review |
194 bytes,
text/plain
|
Details |
After run document.execCommand("insertLineBreak")
and setRangeText
in loop, when malloc failure on nsLineBreaker::FlushCurrentWord()
in if (!breakState.AppendElements(length, mozilla::fallible)) {
Firefox able to crash with SIGSEGV/SEGV_ACCERR with changing address, sometimes SIGILL/ILL_ILLOPN with changing top stack, and ASan heap-use-after-free on nsLineBreaker::FlushCurrentWord()
with READ of size 4 (32-bit) and READ of size 8 (64-bit) ASan build
Tested on:
- Firefox 129.0.2 (32-bit)
- Firefox Nightly 131.0a1 (2024-08-28) (32-bit)
Steps to reproduce:
- Apply attached nsLineBreaker-FlushCurrentWord.patch
- Compile Firefox
- Visit attached testcase.forpatch.html
- Firefox crash with SIGSEGV / SEGV_ACCERR or AddressSanitizer: heap-use-after-free on ASan build
Reporter | ||
Comment 1•11 months ago
|
||
Reporter | ||
Comment 2•11 months ago
|
||
Reporter | ||
Comment 3•11 months ago
|
||
Reporter | ||
Comment 4•11 months ago
|
||
Reporter | ||
Comment 5•11 months ago
|
||
Reporter | ||
Comment 6•11 months ago
|
||
Comment 7•11 months ago
|
||
nsLineBreaker is under dom/ but it looks mostly related to text, so I'll put it in Layout.
I'm marking this sec-moderate because it requires an OOM. If you can demonstrate a reliable test case without patching Firefox, we could probably raise it to sec-high.
Reporter | ||
Comment 8•11 months ago
|
||
(In reply to Andrew McCreight [:mccr8] from comment #7)
I'm marking this sec-moderate because it requires an OOM. If you can demonstrate a reliable test case without patching Firefox, we could probably raise it to sec-high.
Thanks, I originally able to reproduce this on Firefox Nightly 32-bit official build, however the testcase is still intermittent, I'll try to improve the testcase reliability to hit SEGV_ACCERR crash.
I also able to reproduce this on Firefox 115.14.0esr (32-bit).
Reporter | ||
Comment 9•11 months ago
|
||
Comment 10•11 months ago
|
||
Let's start with S2, seems worth fixing.
Assignee | ||
Comment 11•8 months ago
|
||
The problem here occurs because if we bail out of FlushCurrentWord
due to an allocation failure (which could happen for either the breakState
or capitalizationState
arrays), we don't just fail to set up break positions and/or capitalization -- which is the expected result of the failure -- we also miss the final "cleanup" of state that's supposed to happen at the end of FlushCurrentWord
.
That doesn't immediately cause a problem, but it does leave the mTextItems
array holding pointers that were supposed to be cleared, and are about to be freed. So then by the next time we call FlushCurrentWord
those items are no longer valid, and we crash trying to access them.
The fix should be to ensure that we always clear the mTextItems
array when FlushCurrentWord
finishes, even if an error occurred so that we weren't able to set up breaks.
After doing that, the testcase here just happily infinite-loops, as expected. (Presumably it will eventually OOM in some other place, as it is endlessly adding content...)
Assignee | ||
Comment 12•8 months ago
|
||
Updated•8 months ago
|
Comment 13•8 months ago
|
||
![]() |
||
Comment 14•8 months ago
•
|
||
Backed out for non-unified build bustage on nsLineBreaker.cpp:
https://hg.mozilla.org/integration/autoland/rev/03d28e6bd1f816bcdadefd0f0f9de55af1dbdc6d
[task 2024-12-02T18:24:07.272Z] 18:24:07 ERROR - /builds/worker/checkouts/gecko/dom/base/nsLineBreaker.cpp:154:18: error: use of undeclared identifier 'MakeScopeExit'; did you mean 'mozilla::MakeScopeExit'?
[task 2024-12-02T18:24:07.273Z] 18:24:07 INFO - 154 | auto cleanup = MakeScopeExit([&] {
[task 2024-12-02T18:24:07.274Z] 18:24:07 INFO - | ^~~~~~~~~~~~~
[task 2024-12-02T18:24:07.274Z] 18:24:07 INFO - | mozilla::MakeScopeExit
[task 2024-12-02T18:24:07.274Z] 18:24:07 INFO - /builds/worker/workspace/obj-build/dist/include/mozilla/ScopeExit.h:119:39: note: 'mozilla::MakeScopeExit' declared here
[task 2024-12-02T18:24:07.274Z] 18:24:07 INFO - 119 | [[nodiscard]] ScopeExit<ExitFunction> MakeScopeExit(
[task 2024-12-02T18:24:07.274Z] 18:24:07 INFO - | ^
![]() |
||
Updated•8 months ago
|
Assignee | ||
Updated•8 months ago
|
Comment 15•8 months ago
|
||
![]() |
||
Comment 16•8 months ago
|
||
Updated•8 months ago
|
Comment 17•8 months ago
|
||
The patch landed in nightly and beta is affected.
:jfkthame, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox134
towontfix
.
For more information, please visit BugBot documentation.
Assignee | ||
Comment 18•8 months ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D230763
Updated•8 months ago
|
Comment 19•8 months ago
|
||
beta Uplift Approval Request
- User impact if declined: potential use-after-free after a memory-allocation failure
- Code covered by automated testing: no
- Fix verified in Nightly: no
- Needs manual QE test: no
- Steps to reproduce for manual QE testing: n/a
- Risk associated with taking this patch: low
- Explanation of risk level: Just ensures early-return codepaths don't skip required cleanup
- String changes made/needed: none
- Is Android affected?: yes
Assignee | ||
Updated•8 months ago
|
Updated•8 months ago
|
Updated•8 months ago
|
Comment 20•8 months ago
|
||
uplift |
Updated•8 months ago
|
Updated•8 months ago
|
Comment 21•8 months ago
•
|
||
Please nominate this for ESR128 and ESR115 approval. It'll need a minor bit of rebasing for ESR115.
Assignee | ||
Comment 22•8 months ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D230763
Updated•8 months ago
|
Comment 23•8 months ago
|
||
esr128 Uplift Approval Request
- User impact if declined: potential use-after-free after a memory-allocation failure
- Code covered by automated testing: no
- Fix verified in Nightly: no
- Needs manual QE test: no
- Steps to reproduce for manual QE testing: n/a
- Risk associated with taking this patch: low
- Explanation of risk level: Just ensures early-return codepaths don't skip required cleanup
- String changes made/needed: none
- Is Android affected?: yes
Assignee | ||
Comment 24•8 months ago
|
||
Updated•8 months ago
|
Comment 25•8 months ago
|
||
esr115 Uplift Approval Request
- User impact if declined: potential use-after-free after a memory-allocation failure
- Code covered by automated testing: no
- Fix verified in Nightly: no
- Needs manual QE test: no
- Steps to reproduce for manual QE testing: n/a
- Risk associated with taking this patch: low
- Explanation of risk level: Just ensures early-return codepaths don't skip required cleanup
- String changes made/needed: none
- Is Android affected?: yes
Assignee | ||
Updated•8 months ago
|
Updated•8 months ago
|
Updated•8 months ago
|
Comment 26•8 months ago
|
||
uplift |
Updated•8 months ago
|
Comment 27•8 months ago
|
||
uplift |
Updated•8 months ago
|
Updated•7 months ago
|
Comment 28•7 months ago
|
||
Updated•7 months ago
|
Updated•2 months ago
|
Description
•