Closed
Bug 2034816
Opened 6 months ago
Closed 6 months ago
Using ImmPtr instead of ImmGCPtr in a few places
Categories
(Core :: JavaScript Engine: JIT, defect, P2)
Core
JavaScript Engine: JIT
Tracking
()
RESOLVED
FIXED
152 Branch
People
(Reporter: jandem, Assigned: jandem)
References
(Blocks 2 open bugs)
Details
(Keywords: sec-low, Whiteboard: [adv-main152+r])
Attachments
(1 external file)
I had Claude do a MIR instruction audit and one of its findings was that CodeGenerator::visitModuleMetadata and CodeGenerator::visitNewArrayObject use ImmPtr instead of ImmGCPtr. (I had it look for similar cases elsewhere but it didn't find others.)
I think these are safe in practice (and why Mythos didn't report it): we have a shape and a ModuleObject, both are tenured so can't move on nursery GC, they are kept alive through other references, and compacting GC force-discards JIT code before relocating arenas. This is brittle though and it's a very safe and simple fix.
| Assignee | ||
Updated•6 months ago
|
Type: task → defect
| Assignee | ||
Comment 1•6 months ago
|
||
Updated•6 months ago
|
Pushed by jdemooij@mozilla.com:
https://github.com/mozilla-firefox/firefox/commit/c06fbed9bccb
https://hg.mozilla.org/integration/autoland/rev/8127841e1ac1
Change some ImmPtr uses to ImmGCPtr. r=iain
Comment 3•6 months ago
|
||
Group: javascript-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 6 months ago
status-firefox150:
--- → wontfix
status-firefox151:
--- → wontfix
status-firefox152:
--- → fixed
status-firefox-esr115:
--- → wontfix
status-firefox-esr140:
--- → wontfix
Resolution: --- → FIXED
Target Milestone: --- → 152 Branch
Updated•5 months ago
|
QA Whiteboard: [sec] [qa-triage-done-c153/b152]
Updated•5 months ago
|
Whiteboard: [adv-main152+r]
Updated•1 month ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•