2014873 - (CVE-2026-4705) Assertion failure: it != mSsrcToRtxSsrc.end(), at /dom/media/webrtc/jsep/JsepTrack.h:176

Status: RESOLVED FIXED

(Core :: WebRTC: Signaling, defect, P2)

Description

[Jesse Schwartzentruber (:truber)]

Reproduced on mozilla-central rev ed1c0b4f0bbe (built with: --enable-debug --enable-fuzzing).

Testcase can be reproduced using the following commands:

$ pip install fuzzfetch grizzly-framework pipx --upgrade
$ python -m pipx ensurepath
$ fuzzfetch --build ed1c0b4f0bbe --debug --fuzzing  -n firefox
$ grizzly-replay-bugzilla ./firefox/firefox <bugid>

Assertion failure: it != mSsrcToRtxSsrc.end(), at /dom/media/webrtc/jsep/JsepTrack.h:176

    ==2127741==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fa7f888e433 bp 0x7fff309178d0 sp 0x7fff30917880 T2127741)
    ==2127741==The signal is caused by a WRITE memory access.
    ==2127741==Hint: address points to the zero page.
        #0 0x7fa7f888e433 in MOZ_CrashSequence /builds/worker/workspace/obj-build/dist/include/mozilla/Assertions.h:237:3
        #1 0x7fa7f888e433 in mozilla::JsepTrack::GetRtxSsrcs() const /dom/media/webrtc/jsep/JsepTrack.h:176:9
        #2 0x7fa7f888db33 in mozilla::dom::RTCRtpReceiver::UpdateTransport() /dom/media/webrtc/jsapi/RTCRtpReceiver.cpp:750:58
        #3 0x7fa7f88f0a62 in mozilla::dom::RTCRtpTransceiver::UpdateTransport() /dom/media/webrtc/jsapi/RTCRtpTransceiver.cpp:418:14
        #4 0x7fa7f887df3c in mozilla::PeerConnectionImpl::UpdateTransports(mozilla::JsepSession const&, bool) /dom/media/webrtc/jsapi/PeerConnectionImpl.cpp:4281:22
        #5 0x7fa7f88c2d42 in operator() /dom/media/webrtc/jsapi/PeerConnectionImpl.cpp:2984:11
        #6 0x7fa7f88c2d42 in mozilla::detail::RunnableFunction<mozilla::PeerConnectionImpl::DoSetDescriptionSuccessPostProcessing(mozilla::dom::RTCSdpType, bool, RefPtr<mozilla::dom::Promise> const&)::$_0>::Run() /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:549:5
        #7 0x7fa7f3d44497 in mozilla::RunnableTask::Run() /xpcom/threads/TaskController.cpp:705:16
        #8 0x7fa7f3d3eb64 in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) /xpcom/threads/TaskController.cpp:1325:20
        #9 0x7fa7f3d3d7e7 in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) /xpcom/threads/TaskController.cpp:1148:15
        #10 0x7fa7f3d3dc65 in mozilla::TaskController::ProcessPendingMTTask(bool) /xpcom/threads/TaskController.cpp:641:36
        #11 0x7fa7f3d4d776 in operator() /xpcom/threads/TaskController.cpp:333:37
        #12 0x7fa7f3d4d776 in mozilla::detail::RunnableFunction<mozilla::TaskController::TaskController()::$_0>::Run() /xpcom/threads/nsThreadUtils.h:549:5
        #13 0x7fa7f3d5fcf3 in nsThread::ProcessNextEvent(bool, bool*) /xpcom/threads/nsThread.cpp:1168:16
        #14 0x7fa7f3d6594f in NS_ProcessNextEvent(nsIThread*, bool) /xpcom/threads/nsThreadUtils.cpp:461:10
        #15 0x7fa7f4955287 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /ipc/glue/MessagePump.cpp:85:21
        #16 0x7fa7f48ae691 in RunHandler /ipc/chromium/src/base/message_loop.cc:366:3
        #17 0x7fa7f48ae691 in MessageLoop::Run() /ipc/chromium/src/base/message_loop.cc:348:3
        #18 0x7fa7f9a65a68 in nsBaseAppShell::Run() /widget/nsBaseAppShell.cpp:152:27
        #19 0x7fa7f9b31484 in nsAppShell::Run() /widget/gtk/nsAppShell.cpp:555:33
        #20 0x7fa7fab794eb in XRE_RunAppShell() /toolkit/xre/nsEmbedFunctions.cpp:652:20
        #21 0x7fa7f4956134 in mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) /ipc/glue/MessagePump.cpp:235:9
        #22 0x7fa7f48ae691 in RunHandler /ipc/chromium/src/base/message_loop.cc:366:3
        #23 0x7fa7f48ae691 in MessageLoop::Run() /ipc/chromium/src/base/message_loop.cc:348:3
        #24 0x7fa7fab78c4f in XRE_InitChildProcess(int, char**, XREChildData const*) /toolkit/xre/nsEmbedFunctions.cpp:590:34
        #25 0x55c14dc3ff8c in main /browser/app/nsBrowserApp.cpp:465:22
        #26 0x7fa80553df74 in __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
        #27 0x7fa80553e026 in __libc_start_main ./csu/../csu/libc-start.c:360:3
        #28 0x55c14dc13de8 in _start ??:0:0
    
    ==2127741==Register values:
    rax = 0x0000000000000000  rbx = 0x000055c18606c890  rcx = 0x00000000000000b0  rdx = 0x0000000000000000
    rdi = 0x00007fa8056fd780  rsi = 0x0000000000000000  rbp = 0x00007fff309178d0  rsp = 0x00007fff30917880
     r8 = 0x0000000000000000   r9 = 0x0000000000000000  r10 = 0x0000000000000000  r11 = 0x00007fa805ac25c0
    r12 = 0x000055c18606c894  r13 = 0x000055c1867dc560  r14 = 0x000055c186862ae8  r15 = 0x000055c186862a20
    UndefinedBehaviorSanitizer can not provide additional info.
    SUMMARY: UndefinedBehaviorSanitizer: SEGV (/home/truber/builds/m-c-20260205163736-fuzzing-debug/libxul.so+0x948e433) (BuildId: 0b411186bb9521ab7e302998bc6191dc011c2d12)
    ==2127741==ABORTING

Comment 1

[Jesse Schwartzentruber (:truber)]

Attachment: Detailed Crash Information

Comment 2

[Jesse Schwartzentruber (:truber)]

Attachment: Testcase

Comment 3

[Bugmon [:jkratzer for issues]]

Verified bug as reproducible on mozilla-central 20260205213633-279b57ef4bf0.
Unable to bisect testcase (Testcase reproduces on start build!):

Start: ce0f77cae5a91e2cb4b1ec859117e08aa1182c52 (20250207164009)
End: ed1c0b4f0bbef7e458685d5f4743c73ae66cc3fd (20260205163736)
BuildFlags: BuildFlags(asan=False, tsan=False, debug=True, fuzzing=True, coverage=False, valgrind=False, no_opt=False, fuzzilli=False, nyx=False, searchfox=False, afl=False)

Comment 4

[Nico Grunbaum [:ng, @chew:mozilla.org]]

I have filed cover bug 2015211 .

Comment 6

[Andrew McCreight [:mccr8]]

Why did you rate this a sec-moderate? What is the security issue here? Thanks.

Comment 7

[Nico Grunbaum [:ng, @chew:mozilla.org]]

(In reply to Andrew McCreight [:mccr8] from comment #6)

Why did you rate this a sec-moderate? What is the security issue here? Thanks.

Hi Andrew, here is what I know:

In non-release builds this will read an invalid iterator on the next line. https://searchfox.org/firefox-main/rev/e7f79d7d80b01b4d4b4d961124ef960ba9ab30a7/dom/media/webrtc/jsep/JsepTrack.h#177
It is trivially easy to trigger with a crafted SDP. I am unaware of any way in which this could specifically be abused, or of active abuse in the wild.

I based my rating on what I read in the following resources:
https://firefox-source-docs.mozilla.org/bug-mgmt/processes/fixing-security-bugs.html
https://firefox-source-docs.mozilla.org/bug-mgmt/processes/security-approval.html
https://bugzilla.mozilla.org/describekeywords.cgi

I haven't triaged too many of these so any additional guidance would be appreciated.

Comment 8

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Attachment: (secure)

Comment 9

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Attachment: (secure)

Comment 10

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Attachment: (secure)

Comment 11

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Attachment: (secure)

Comment 12

[Bugmon [:jkratzer for issues]]

Testcase crashes using the initial build (mozilla-central 20260205163736-ed1c0b4f0bbe) but not with tip (mozilla-central 20260213212122-0d74a4189e30.)

The bug appears to have been fixed in the following build range:

Start: 5b22478f4f4f3feaad5e4ade78a335afe07e673e (20260212064912)
End: 8cf0013141048f4a1ab8dfe12e60de915164be1b (20260212081829)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5b22478f4f4f3feaad5e4ade78a335afe07e673e&tochange=8cf0013141048f4a1ab8dfe12e60de915164be1b

ng, can you confirm that the above bisection range is responsible for fixing this issue?
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.

Comment 13

[Nico Grunbaum [:ng, @chew:mozilla.org]]

(In reply to Bugmon [:jkratzer for issues] from comment #12)

Testcase crashes using the initial build (mozilla-central 20260205163736-ed1c0b4f0bbe) but not with tip (mozilla-central 20260213212122-0d74a4189e30.)

The bug appears to have been fixed in the following build range:

Start: 5b22478f4f4f3feaad5e4ade78a335afe07e673e (20260212064912)
End: 8cf0013141048f4a1ab8dfe12e60de915164be1b (20260212081829)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5b22478f4f4f3feaad5e4ade78a335afe07e673e&tochange=8cf0013141048f4a1ab8dfe12e60de915164be1b

ng, can you confirm that the above bisection range is responsible for fixing this issue?
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.

Yes, that range includes a fix.

Comment 14

[Andrew McCreight [:mccr8]]

It looks like this find call was added in bug 1852775, so I think esr115 is not actually affected.

Comment 15

[Andrew McCreight [:mccr8]]

As described above, what happens in a non-debug build should be that an end iterator for a std::map will be accessed. Because this is a map and not like a vector, hopefully the behavior isn't so bad.

Comment 16

[Andrew McCreight [:mccr8]]

I tried the test case in a non-debug ASan build and nothing happened.

Comment 17

[Andrew McCreight [:mccr8]]

[Tracking Requested - why for this release]: probably not so bad but we should at least uplift this to ESR140. Note that it is fixed in 149 but not 148.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for ESR140 uplift when you get a chance.

Comment 19

[Nico Grunbaum [:ng, @chew:mozilla.org]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #18)

Please nominate this for ESR140 uplift when you get a chance.

Thanks, done.