921090 - Upgrade Firefox to NSS 3.15.2 to fix bug 894370

Status: RESOLVED FIXED

(Firefox :: Security, defect, P1)

Description

[Daniel Veditz [:dveditz] back January 5, 2026]

+++ This bug was initially created as a clone of Bug #894370 +++

We need to fix NSS security bug 894370 in older Firefox branches. mozilla-central and -aurora (firefox 26+) already have NSS 3.15.2 containing this fix, but Firefox ESR-24 and Firefox 25 (aurora) are currently using NSS 3.15.1 which does not.

ESR-17 and b2g18 branches are using the older NSS 3.14.3 which is affected, but we don't think this sec-moderate bug is severe enough to worry about on those EOL/near-EOL branches given the larger NSS jump required.

Comment 1

[Lukas Blakk [:lsblakk] use ?needinfo]

Kaie - can you take this?

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

https://hg.mozilla.org/releases/mozilla-beta/rev/ee766b7c606e
https://hg.mozilla.org/releases/mozilla-esr24/rev/30211e06b00a

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I suggest that we fix bug 894370 for b2g18 by applying the patch for bug 894370 directly to the mozilla-b2g18 repo, instead of upgrading all of NSS in mozilla-b2g18 to NSS 3.15.2. Note that we already have two other private patches to NSS in mozilla-b2g18.

bug 894370 is a bug fix to the code that prevents the Lucky 13 attack and is sec-moderate. The patch for bug 894370 applies cleanly to the mozilla-b2g18 branch.

The mozilla-b2g18 branch uses NSS 3.14.3, which apparently was before we did the big switch to NSS and before we re-arranged the NSS directory structure (e.g. before we moved security/coreconf to be security/nss/coreconf and before we moved security/dbm to be security/nss/lib/dbm). To upgrade NSS 3.14.3 all the way to NSS 3.15.2 in mozilla-beta we would need to make updates to the customized build system we have for NSS in Gecko (security/build). In addition, we will get all the TLS 1.2 code and other unrelated fixes.

This seems like a lot of changes to be adding to a branch that is supposed to be very stable and which Aki said is supposed to be limited to chemspill-type bug fixes.

Dan, does applying the patch for bug 894370 as a private patch sound reasonable to you?

Comment 4

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Also, what to do about ESR17? I suggest we apply the patch as a private patch for ESR17 too, BUT change configure.in to require NSS 3.15.2 for when --use-system-nss is used.

Comment 5

[Mike Hommey [:glandium]]

sounds fair enough.

Comment 6

[Daniel Veditz [:dveditz] back January 5, 2026]

> Dan, does applying the patch for bug 894370 as a private patch
> [to b2g18] sound reasonable to you?

To b2g18, certainly.

(In reply to Brian Smith (:briansmith, was :[e-mail]) from comment #4)
> Also, what to do about ESR17? I suggest we apply the patch as a private
> patch for ESR17 too, BUT change configure.in to require NSS 3.15.2 for when
> --use-system-nss is used.

Sounds OK since we've only got one last ESR17 release. Can we fiddle the version strings so the DLLs don't claim to be stock 3.14.3?

Comment 7

[Al Billings [:abillings - ex-MoCo]]

Are we checking in something for ESR17 here, Brian?

Comment 8

[Matt Wobensmith [:mwobensmith][:matt:]]

I think Brian is out today. I'm guessing that our time is running out for 17esr. Sid, any ideas?

Comment 9

[bhavana bajaj [:bajaj]]

needinfo :dveditz to help with the decision on esr17 here , given the gtb timeline.

Comment 10

[Sid Stamm [:geekboy or :sstamm]]

I'm working through this with the nss dev team to make a new release NSS 3.14.4 which is 3.14.3 plus the patch in 894370 so we don't have to fiddle with version strings (for the DLL).

Do we still want the changes to Configure.in? I'm unaware of what effect that will have on linux distros where users want system NSS but don't have access to the latest and greatest 3.15.2.

Comment 11

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

-> sid based on comment 10.

(In reply to Sid Stamm [:geekboy or :sstamm] from comment #10)
> I'm working through this with the nss dev team to make a new release NSS
> 3.14.4 which is 3.14.3 plus the patch in 894370 so we don't have to fiddle
> with version strings (for the DLL).
> 
> Do we still want the changes to Configure.in? I'm unaware of what effect
> that will have on linux distros where users want system NSS but don't have
> access to the latest and greatest 3.15.2.

If you make an NSS 3.14.4 then you need to change configure.in to require NSS 3.14.4 or later. If we skip the NSS 3.14.4 release then we need to change configure.in to require NSS 3.15.2. If you don't change configure.in then it is almost guaranteed that some Linux distros that configure Firefox to use system NSS won't be updated with the bug fix (this has happened before in similar situations when we forgot to update configure.in).

Comment 12

[Kai Engert [:KaiE:]]

(In reply to Brian Smith (:briansmith, was :[e-mail]) from comment #11)
> > 
> If you make an NSS 3.14.4 then you need to change configure.in to require
> NSS 3.14.4 or later. If we skip the NSS 3.14.4 release then we need to
> change configure.in to require NSS 3.15.2. If you don't change configure.in
> then it is almost guaranteed that some Linux distros that configure Firefox
> to use system NSS won't be updated with the bug fix (this has happened
> before in similar situations when we forgot to update configure.in).


While this is reasonable, it has been forgotten on earlier updates to the ESR 17 branch. That branch currently uses NSS 3.14.3, but the min_nss_version set in configure.in is still at the much older version 3.13.2

So, if you want to minimize changes on ESR 17, you could keep the min_nss_version in configure.in - Obviously, ESR 17 already relies on distribution package maintainers to be smart and doublecheck which NSS version is necessary.

On the other hand, updating configure.in forces admins to notice, and given we create an updated release, all consumers of ESR 17 who separately build NSS should be able to upgrade their NSS version, too.

Comment 13

[Kai Engert [:KaiE:]]

Attachment: update ESR17 to 3.14.4 RC0

I've create a NSS 3.14.4 release candidate (RC0). I'm waiting for Bob or Wan-Teh to approve the release as prepared.

This is a patch that updates ESR 17 to that RC0. Let's wait a bit until I get a "go".

Comment 14

[Kai Engert [:KaiE:]]

Notice to self: When landing, also update TAG-INFO, TAG-INFO-CKBI to the final release tag, and the dummy whitespace change to coreconf.dep.

Comment 15

[Kai Engert [:KaiE:]]

Attachment: update ESR17 to 3.14.4 RTM - final patch

Comment 16

[Kai Engert [:KaiE:]]

Attachment: upgrade configure[.in] to require NSS 3.14.4 at build time

Comment 17

[Sid Stamm [:geekboy or :sstamm]]

Comment on attachment 820575 [details] [diff] [review]
update ESR17 to 3.14.4 RTM - final patch

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: 
Fix Landed on Version:
Risk to taking this patch (and alternatives if risky): 
String or UUID changes made by this patch: 

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: is regression and sec-moderate, want our users to be safe
User impact if declined: users of esr may be vulnerable to attack
Fix Landed on Version: fix is in bug 894370 (fx 26+, also in latest NSS)
Risk to taking this patch (and alternatives if risky): minimal, fixes a bug in old version of NSS used by ESR17
String or UUID changes made by this patch: none


dveditz: I assume we should upgrade configure.in as well (attachment 820581 [details] [diff] [review])?

Comment 18

[Daniel Veditz [:dveditz] back January 5, 2026]

Adding the two other bugs included in the patch to the depends on list. (Bug 832942 and Bug 863947)

Comment 19

[Daniel Veditz [:dveditz] back January 5, 2026]

Comment on attachment 820575 [details] [diff] [review]
update ESR17 to 3.14.4 RTM - final patch

ESR-17 didn't really need those two extra patches, but they don't increase the risk much and I'd rather use an officially-blessed NSS release than not and this is preferable to the much larger 3.15.x upgrade.

a=dveditz

Comment 20

[Kai Engert [:KaiE:]]

Checked in
https://hg.mozilla.org/releases/mozilla-esr17/rev/73391f62b265

We agreed that we better not upgrade configure.in, but I accidentally had included it.
Backed that out:
https://hg.mozilla.org/releases/mozilla-esr17/rev/c3750e0515f7

Comment 21

[Kai Engert [:KaiE:]]

Can you please mention in the ESR 17 release notes that Firefox 17.0.10 should be used with NSS 3.14.4 (or alternatively using NSS 3.15.2 or later)?

Comment 22

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Kai Engert (:kaie) from comment #21)
> Can you please mention in the ESR 17 release notes that Firefox 17.0.10
> should be used with NSS 3.14.4 (or alternatively using NSS 3.15.2 or later)?

This is why we update configure.in. Why wouldn't we want to update configure.in? We know from past experience that when we don't, Linux distros don't upgrade NSS.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

Do we want this on b2g18 as well?