Firefox · Networking
CVE-2026-12312
Logic Error in Networking
Overview
Medium
Severity
—
CVSS
No
Exploited ITW
Fixed
Fix Status
Background
- TRR
- Trusted Recursive Resolver, Firefox’s DNS-over-HTTPS client that resolves hostnames over an encrypted HTTPS channel instead of plaintext UDP DNS.
- DNS additional section
- an optional part of a DNS response that carries extra resource records (such as
A/AAAAaddress records) beyond the direct answer to the query. - `network.trr.add_additional_records`
- a
RelaxedAtomicBoolstatic preference gating whether IPs found in a response’s additional section are folded into the DNS cache. - Static preference
- a compile-time-declared pref in
StaticPrefList.yamlwhose default value and mirroring behavior are fixed at build time.
Root Cause Analysis
The vulnerable path is the TRR response parser that, when network.trr.add_additional_records was true, walked the DNS additional section and inserted the extra A/AAAA records it found into the host cache. Because the metadata classifies this as a LogicError/memory-safety bug in Networking, the parsing/insertion of those additional-section records violated an invariant about which records may be trusted and stored, letting a malformed or hostile response drive the cache-population code into an unsafe state. The diff itself does not alter that parsing code; instead it flips the pref default from true to false, so the additional-section records are no longer consumed by default and the buggy code path is not reached in normal operation. The accompanying test change in test_trr_additional_section.js re-enables the pref explicitly so the feature’s behavior can still be exercised under test.
The fix works as mitigation by removing attacker reachability of the flawed path rather than by correcting the parsing logic in this commit.
Key insight
The core mistake was trusting and caching address records drawn from the DNS response’s additional section, an attacker-influenced region that should not populate the host cache; the fix neutralizes it by defaulting
network.trr.add_additional_records to false so those records are ignored.Attack Path
- Control the resolver channel The attacker operates or is able to influence the responses returned by the TRR/DoH endpoint the victim uses.
- Craft a malicious response They return a DNS response containing crafted or excess records in the additional section beyond the queried answer.
- Trigger additional-record ingestion
With
network.trr.add_additional_recordsat its old default oftrue, Firefox parses those additional records and feeds them into the cache-population path. - Drive the flawed logic The malformed additional-section input pushes the record-handling code into the memory-unsafe state described by the bug’s classification.
Impact Assessment
An attacker who controls TRR/DoH responses can reach a memory-safety defect in the networking parent process’s DNS resolution path, rated moderate impact. Preconditions are that TRR is active and that the old default enabling additional-record ingestion is in force, meaning the attacker must be positioned to supply the resolver responses the victim consumes. The disabled default removes routine reachability, leaving exploitation contingent on the feature being explicitly re-enabled.
Files Changed
modules/libpref/init/StaticPrefList.yamlnetwerk/test/unit/test_trr_additional_section.js
Audit Directions
- Additional/authority section trustReview any code that ingests records from DNS additional or authority sections into caches, and confirm each is validated and bailiwick-checked before storage.
- Pref-gated dangerous pathsAudit features whose only safety guarantee is a disabled pref default, since the underlying parsing bug remains reachable whenever the pref is turned on.
- TRR response parsing boundsTrace the TRR/DoH response decoder for record-count and buffer handling to find the unfixed memory-safety flaw that the pref change merely masks.
Patch
diff --git a/modules/libpref/init/StaticPrefList.yaml b/modules/libpref/init/StaticPrefList.yaml
index 4a7f1a68027..9fdee5c227f 100644
--- a/modules/libpref/init/StaticPrefList.yaml
+++ b/modules/libpref/init/StaticPrefList.yaml
@@ -16446,7 +16446,7 @@
# Whether to add additional record IPs to the cache
- name: network.trr.add_additional_records
type: RelaxedAtomicBool
- value: true
+ value: false
mirror: always
# When true, the HTTP cache uses the No-Vary-Search response header to match
diff --git a/netwerk/test/unit/test_trr_additional_section.js b/netwerk/test/unit/test_trr_additional_section.js
index bd8b300b968..445e213db21 100644
--- a/netwerk/test/unit/test_trr_additional_section.js
+++ b/netwerk/test/unit/test_trr_additional_section.js
@@ -5,6 +5,8 @@
"use strict";
trr_test_setup();
+Services.prefs.setBoolPref("network.trr.add_additional_records", true);
+
registerCleanupFunction(async () => {
trr_clear_prefs();
});
Loading diff…
Regression Test / PoC
shipped with the fix
diff --git a/netwerk/test/unit/test_trr_additional_section.js b/netwerk/test/unit/test_trr_additional_section.js
index bd8b300b968..445e213db21 100644
--- a/netwerk/test/unit/test_trr_additional_section.js
+++ b/netwerk/test/unit/test_trr_additional_section.js
@@ -5,6 +5,8 @@
"use strict";
trr_test_setup();
+Services.prefs.setBoolPref("network.trr.add_additional_records", true);
+
registerCleanupFunction(async () => {
trr_clear_prefs();
});
Loading diff…
References
On This Page