Closed Bug 1868673 Opened 7 months ago Closed 7 months ago

undefined behavior with gNeuteredWindows delete in MessageChannel::SyncStackFrame()

Categories

(Core :: IPC, defect)

Unspecified
Windows
defect

Tracking

()

RESOLVED FIXED
122 Branch
Tracking Status
firefox-esr115 --- wontfix
firefox120 --- wontfix
firefox121 --- wontfix
firefox122 --- fixed

People

(Reporter: mozillabugs, Assigned: mccr8)

Details

(Keywords: csectype-undefined, reporter-external, sec-low, Whiteboard: [adv-main122-])

Attachments

(1 file)

MessageChannel::SyncStackFrame() (ipc/glue/WindowsMessageLoop.cpp) invokes undefined behavior by deleting an object whose static type lacks a virtual destructor, where the object has a derived-class dynamic type. [1] The base class involved is nsTArray, and the derived class is AutoTArray.

The base-class object pointer is defined thusly (line numbers from current trunk)

92: nsTArray<HWND>* gNeuteredWindows = nullptr;

and the new expression:

621: MessageChannel::SyncStackFrame::SyncStackFrame(MessageChannel* channel)
...
638:     gNeuteredWindows = new AutoTArray<HWND, 20>();

and the delete expression:

643: MessageChannel::SyncStackFrame::~SyncStackFrame() {
...
658:     delete gNeuteredWindows;

[1] See C++ 20 Standard (n4750) s.8.5.2.5(3) : "In a single-object delete expression, if the static type of the object to be deleted is different from its dynamic type, the static type shall be a base class of the dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undefined."

Flags: sec-bounty?
Group: core-security → dom-core-security

I'm not sure how to rate this. I think AutoTArray doesn't do anything in its destructor so the specific mismatch doesn't matter, unless I guess the compiler notices and decides to do something nasty? I think the fix is to change the type of the global to AutoTArray.

Keywords: sec-other

It looks like this started out with gNeuteredWindows not being an owning pointer, so delete wasn't called on it, but later bug 538918 changed it to be an owning pointer and that introduced the delete (in a followup patch), and thus the undefined behavior, but it does look like the global was always an nsTArray and always had an auto array assigned into it.

Summary: UB in MessageChannel::SyncStackFrame() → undefined behavior with gNeuteredWindows delete in MessageChannel::SyncStackFrame()
Keywords: sec-othersec-low

I think the easiest fix here is to change the type of gNeuteredWindows to AutoTArray.

Assignee: nobody → continuation

I have a patch. This is Windows-only so I'll do a try push before putting it up for review.

Also, new is infallible, so remove a check.

Pushed by amccreight@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/191f89706c7b
Use StaticAutoPtr for gNeuteredWindows r=handyman
Group: dom-core-security → core-security-release
Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → 122 Branch
Flags: sec-bounty? → sec-bounty+
QA Whiteboard: [post-critsmash-triage]
Flags: qe-verify-
Whiteboard: [adv-main122-]

Making Firefox 122 security bugs public. [bugspam filter string: Pilgarlic-Towers]

Group: core-security-release
You need to log in before you can comment on or make changes to this bug.