Closed Bug 1867408 (CVE-2024-0743) Opened 6 months ago Closed 6 months ago

Crash in [@ ssl_SendSavedWriteData | ssl3_SendRecord | ssl3_FlushHandshakeMessages | ssl3_FlushHandshake | tls13_SendClientSecondFlight ]


(NSS :: Libraries, defect, P2)



(firefox-esr115124+ fixed, firefox120 wontfix, firefox121 wontfix, firefox122 fixed)

Tracking Status
firefox-esr115 124+ fixed
firefox120 --- wontfix
firefox121 --- wontfix
firefox122 --- fixed


(Reporter: jschanck, Assigned: jschanck)



(Keywords: csectype-bounds, sec-high, Whiteboard: [post-critsmash-triage][adv-main122+][adv-esr115.9+])

Crash Data


(2 files)

We see a few hundred instances per month of an EXC_BAD_ACCESS crash in ssl_SendSavedWriteData on macOS.

The crash is in this memmove:

        rv = ssl_DefSend(ss, ss->pendingBuf.buf, ss->pendingBuf.len, 0);
        if (rv < 0) {
            return rv;
        ss->pendingBuf.len -= rv;
        if (ss->pendingBuf.len > 0 && rv > 0) {
            /* UGH !! This shifts the whole buffer down by copying it */
            PORT_Memmove(ss->pendingBuf.buf, ss->pendingBuf.buf + rv,


We're failing to check that ss->pendingBuf.len >= rv before performing ss->pendingBuf.len -= rv;. The ss->pendingBuf.len > 0 clause in the if statement won't catch this error because ss->pendingBuf.len is unsigned.

I'll post a patch to avoid the symptom, but the underlying problem (rv > ss->pendingBuf.len) should also be addressed. I don't know the code (or macOS) well enough to see why that would happen.

I only see 21 crashes the last 3 months for [@ ssl_SendSavedWriteData | ssl3_SendRecord | ssl3_FlushHandshake | tls13_SendClientSecondFlight], and they are all on the unsupported ESR-102 branch. The crashes stop in October so I imagine those folks got upgraded to ESR-115

For the other signature, ESR-115 releases have a lot more crashes than the mainline releases. If we throttle Mac release crashes as we do Windows that would make sense, but I was pretty sure the 10% sampling was for "Release on Windows" only. We have fewer users on other OSs and channels so we need to process all the crashes we get. Either I'm wrong about the sampling, or it looks like we've fixed at least one cause that lead to this crash signature since Firefox 115.

Guessing this could be sec-high because it's an out of bounds issue, assuming this is triggered by data sent from an attacker's site

The severity field for this bug is set to S3. However, the bug is flagged with the sec-high keyword.
:jschanck, could you consider increasing the severity of this security bug?

For more information, please visit BugBot documentation.

Flags: needinfo?(jschanck)

(NSS follows slightly different practices than Firefox for sec revisions. We approved the landing of this patch in our weekly meeting.)

Closed: 6 months ago
Flags: needinfo?(jschanck)
Resolution: --- → FIXED
Group: crypto-core-security → core-security-release
Target Milestone: --- → 3.96
Flags: qe-verify-
Whiteboard: [post-critsmash-triage]
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main122+]
Whiteboard: [post-critsmash-triage][adv-main122+] → [post-critsmash-triage][adv-main122+r]
Whiteboard: [post-critsmash-triage][adv-main122+r] → [post-critsmash-triage][adv-main122+]
Alias: CVE-2024-0743

Is there a timeline for this fix to be available in firefox-esr115?

Flags: needinfo?(jschanck)
Blocks: 1880562

This is included in NSS 3.90.2 (released on Feb 15, 2024). Uplift to ESR 115 is tracked in Bug 1880562.

Fixed for 115.9esr by 1880562 which was just uplifted to esr115

Flags: needinfo?(jschanck)
Whiteboard: [post-critsmash-triage][adv-main122+] → [post-critsmash-triage][adv-main122+][adv-esr115.9+]

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.