2027501 - (CVE-2026-6753) OOB heap read/write in dcSCTP NackBetweenAckBlocks via crafted SACK chunks

Status: RESOLVED FIXED

(Core :: WebRTC, defect)

Description

[jmwebdevelopement]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36

Steps to reproduce:

Manual source code review of third_party/libwebrtc/net/dcsctp/tx/outstanding_data.cc identified that NackBetweenAckBlocks() iterates TSNs up to an attacker-controlled gap_ack_blocks end value with only RTC_DCHECK bounds checking — compiled out in release Firefox. Critical asymmetry: sibling function AckGapBlocks() in the same file HAS runtime bounds checks, NackBetweenAckBlocks() does not. Missing upstream fix commit fd2e7ea (webrtc:495700476).

Actual results:

A malicious WebRTC DataChannel peer can send crafted SACK chunks with gap block end=60000 during fast recovery (trivially triggered by inducing packet loss). NackBetweenAckBlocks iterates ~59,993 TSNs beyond the deque boundary, each iteration calling GetItem() which reads AND writes 3 heap fields (nack_count_, ack_state_, lifecycle_) plus 5 global counters. This provides an OOB heap read/write primitive. The file has 23 RTC_DCHECK and 0 RTC_CHECK — zero runtime bounds protection in release Firefox.

Expected results:

NackBetweenAckBlocks should have the same runtime bounds checks as its sibling function AckGapBlocks. The upstream fix (commit fd2e7ea, webrtc:495700476) adds these checks. Firefox should import this fix.

Comment 1

[jmwebdevelopement]

Additional finding from the same upstream commit (fd2e7ea): IsSackValid() also lacks GapAckBlock range validation that was added by the same fix. Firefox is missing two defense layers from this commit — the NackBetweenAckBlocks loop bound AND the IsSackValid GapAckBlock validation. Both are minimal patches (2-8 lines each).

Comment 2

[Daniel Veditz [:dveditz]]

https://webrtc-review.googlesource.com/c/src/+/460720
https://webrtc.googlesource.com/src/+/fd2e7ea6206c28d5a567b7bf7e95d77b515851c8

The patch applies and we have coverage data for these two files, but I don't know if this code could be reached with the vulnerable conditions. This patch links to a webrtc issue and not a chromium one so I don't know if it's been acknowledged as a problem in Chrome yet.

Comment 3

[Michael Froman [:mjf]]

Attachment: (secure)

Comment 4

[Michael Froman [:mjf]]

Byron, I combined two upstream patches for this fix:
43845d364d: dcsctp: Correct Fast Recovery retransmission logic
fd2e7ea620: Fix potential dcSCTP NackBetweenAckBlocks OOB access

This makes it a bit less clear what is actually being fixed. I'll add the cherry-pick markers for those two patches in a separate commit later along with some other patch-stack clean up.

Comment 5

[Byron Campen [:bwc]]

Ok, got it.

Comment 6

[Michael Froman [:mjf]]

Comment on attachment 9560829 [details]
(secure)

Security Approval Request

• How easily could an exploit be constructed based on the patch?: The additional bounds check embedded among the other logic corrections on retransmission makes this unlikely.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
• Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: all
• If not all supported branches, which bug introduced the flaw?: 1876843 (libwebrtc v121)
• Do you have backports for the affected branches?: No
• If not, how different, hard to create, and risky will they be?: probably not hard
• How likely is this patch to cause regressions; how much testing does it need?: not likely
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: Unknown

Comment 7

[Daniel Veditz [:dveditz]]

Do you have a testcase that shows this vulnerability can be triggered in Firefox?

Comment 8

[jmwebdevelopement]

this was found through source review i dont have a working testcase that triggers it in a live browser. the code path is reachable through WebRTC DataChannel with crafted SACK chunks during fast recovery but i havent built a full end to end poc for it yet.

the upstream fix (fd2e7ea) confirms the issue is real they added the bounds check that was missing i can try to build a testcase if needed.

Comment 9

[Tom Ritter [:tjr]]

Comment on attachment 9560829 [details]
(secure)

Approved to land and request uplift

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/6903b9ffd61c
https://hg.mozilla.org/integration/autoland/rev/32071ccb68af
fix fast recovery retransmission logic. r=bwc

Comment 11

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: A malicous WebRTC DataChannel peer could craft SACK chunks that allow OOB read/write access.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: no
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: The patch is fairly simple and is a combination of two upstream libwebrtc patches that we would pick in a month or two.
• String changes made/needed?: n/a
• Is Android affected?: yes

Comment 12

[Michael Froman [:mjf]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D291024

Comment 13

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined/Reason for urgency: A malicous WebRTC DataChannel peer could craft SACK chunks that allow OOB read/write access.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: no
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: The patch is fairly simple and is a combination of two upstream libwebrtc patches that we would pick in a month or two.
• String changes made/needed?: n/a
• Is Android affected?: yes

Comment 14

[Michael Froman [:mjf]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D291024

Comment 15

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined/Reason for urgency: A malicous WebRTC DataChannel peer could craft SACK chunks that allow OOB read/write access.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: no
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: The patch is fairly simple and is a combination of two upstream libwebrtc patches that we would pick in a month or two.
• String changes made/needed?: n/a
• Is Android affected?: yes

Comment 16

[Michael Froman [:mjf]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D291024

Comment 17

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/32071ccb68af

Comment 18

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/106403b5d8fb
https://hg.mozilla.org/releases/mozilla-beta/rev/16ea1e252bd5

Comment 19

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/2c534db61a29

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Can we get a sec rating assigned to this?

Comment 21

[Michael Froman [:mjf]]

I'm probably not the right person to make that choice, but we'll go with sec-high to be safe.