Closed
Bug 1791596
Opened 3 years ago
Closed 3 years ago
UaF in [@ mozilla::AudioSegment::Mix ]
Categories
(Core :: WebRTC: Audio/Video, defect)
Core
WebRTC: Audio/Video
Tracking
()
RESOLVED
DUPLICATE
of bug 1605894
Tracking | Status | |
---|---|---|
firefox107 | --- | affected |
People
(Reporter: jib, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: csectype-uaf)
STRs:
- In about:config set
media.getusermedia.audiocapture.enabled
totrue
- Open https://jsfiddle.net/jib1/zecvu1dz/16/
- Wait, or twiddle the pause/play button of the element for a while seems to help
Expected result: No crash
Actual result: bp-9ee9c0fe-9b4c-45aa-8757-46ed10220919
The crash address 0x000000010c920000
suggests a UaF.
Reproed at least twice on macOS. I have to wait a bit, usually 10 seconds or more, but then it seems to hit reliably for me.
Updated•3 years ago
|
Group: core-security → media-core-security
Updated•3 years ago
|
Keywords: csectype-uaf
Comment 1•3 years ago
|
||
This looks like it could be a dupe of bug 1605894. The crash report has PHC information in there. It says "PHC Kind" is "GuardPage", which maybe is more of a buffer overflow like the other bug?
See Also: → 1605894
Comment 2•3 years ago
|
||
I tested with an ASan builds and got the same results as seen in bug 1605894.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
![]() |
||
Updated•2 years ago
|
Blocks: audio-sharing
Updated•1 year ago
|
Group: media-core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•