Closed Bug 1800446 Opened 2 years ago Closed 1 year ago

AddressSanitizer: heap-use-after-free [@ operator bool] with READ of size 8 through [@ WorkerScriptLoader::CancelMainThread]

Categories

(Core :: DOM: Workers, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
109 Branch
Tracking Status
firefox-esr102 --- unaffected
firefox107 --- wontfix
firefox108 --- wontfix
firefox109 + fixed

People

(Reporter: decoder, Assigned: yulia)

References

Details

(4 keywords, Whiteboard: [post-critsmash-triage][adv-main109+r])

Attachments

(1 file)

The attached crash information was submitted via the ASan Nightly Reporter on mozilla-central-asan-nightly revision 108.0a1-20221112215806-https://hg.mozilla.org/mozilla-central/rev/6479051196c1165c23a1964a00422e3be55f7ff1.

For detailed crash information, see attachment.

Component: General → DOM: Workers
Flags: sec-bounty?
Summary: AddressSanitizer: heap-use-after-free [@ operator bool] with READ of size 8 → AddressSanitizer: heap-use-after-free [@ operator bool] with READ of size 8 through [@ WorkerScriptLoader::CancelMainThread]

After bug 1797327 landed it seems there are still raw WorkerLoadContext* passed as a (copied) list into a runnable and one of these has been freed before the runnable was executed.

Flags: needinfo?(ystartsev)
Flags: needinfo?(bugmail)

Ok. I am already reverting the behavior, so this should be fixed by the revert.

Flags: needinfo?(ystartsev)
Assignee: nobody → ystartsev
Depends on: 1800496

Now that bug 1800496 landed - are we confident enough to close this?

Flags: needinfo?(bugmail) → needinfo?(ystartsev)

This can be closed as we are no longer copying the array.

Flags: needinfo?(ystartsev)

Fixed by the changes in bug 1800496. Does that patch need uplift to beta 108 then?

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED

The changes may need an uplift as we keep getting reports related to this.

See Also: → 1793407

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1793407#c4 where Yulia started talking about reverting the earlier changes back in October

Group: dom-core-security → core-security-release
Target Milestone: --- → 109 Branch

Just Following up on this since we are nearing the end of our beta cycle this week.
Can i get some clarification on what we are trying to uplift to fx108? Are we suggesting to uplift bug 1800496 (which seems very risky so late in the cycle) or are we trying to revert some behavior introduced in 108?
Thank you in advance!

Flags: needinfo?(ystartsev)

I believe it is too risky to uplift bug 1800496, as there are two follow up patches fixing behavior, so the sequence would be quite large. I think it should bake longer on nightly.

Flags: needinfo?(ystartsev)

Looks like this bug was fixed regardless of this report. We knew the implementation had issues and worked on it independently (see other bug).
Thanks for reporting this, but at this time we're not awarding a bounty.

Flags: sec-bounty? → sec-bounty-
Flags: qe-verify-
Whiteboard: [post-critsmash-triage]
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main109+r]
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: