Bug 2086039 - Refactor `isFxaPairingLink` check to be scoped to the current FXA server and exact URI path by t-p-white · Pull Request #423 · mozilla-firefox/firefox

t-p-white · 2026-10-28T14:31:27Z

Lando: link
Bugzilla: bug 2086039

⚠️ This pull request has 2 warnings.
🚫 This pull request has 1 blocker.

t-p-white · 2026-10-28T14:34:02Z

https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=111058

corentinbect

Looking good, thanks!

I added two small nit

t-p-white · 2026-10-28T16:41:48Z

https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=111173

mozilla-code-review · 2026-10-28T19:10:44Z

No new issues detected. This pull request is 🆗

mozilla-code-review · 2026-10-28T19:18:52Z

No new issues detected. This pull request is 🆗

t-p-white · 2026-11-02T13:59:30Z

https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=113140

…urrent FXA server and exact URI path.

mozilla-code-review

1 issue has been found in this revision.

1 issue is located outside of the files touched by the patch:

Cargo.lock Error: Crate depends on a vulnerable version of zip.

Advisory:
zip: ZipArchive::extract aborts the process on a symlink entry with a large declared size
Package: zip
ID: RUSTSEC-2026-0429
CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Report date: 2026-10-22
ZipArchive::extract() sizes the symlink-target buffer from the uncompressed
size declared in the central directory record, before reading a single byte of
entry data:

let mut target = Vec::with_capacity(file.size() as usize);

Both inputs are attacker-controlled. ZipFile::size() returns
uncompressed_size verbatim from the central directory, widened to a full u64
by a ZIP64 extended-information extra field, and is never cross-checked against
the compressed size, the remaining archive length, or any platform-appropriate
bound for a symlink target. ZipFile::is_symlink() is decided entirely by the
S_IFLNK bit of the external-attributes field.

Vec::with_capacity() is infallible: when the reservation is refused it calls
handle_alloc_error() and aborts the process. This is not a Rust panic. It is
not caught by catch_unwind(), is unaffected by panic = "unwind", and is not
contained by running the call on a worker thread.

A 112-byte archive is sufficient. One Stored entry flagged S_IFLNK with a
ZIP64 field declaring uncompressed_size = 2^62 and a zero-byte payload makes
extract() fail with:

memory allocation of 4611686018427387904 bytes failed
Aborted (core dumped)          # exit 134

The declared value only needs to exceed the host's address space, not its RAM:
Vec::with_capacity() maps address space without touching pages, so resident
memory stays flat and the abort happens on the refused reservation itself. Under
a ulimit -v cap or a memory-constrained container the threshold drops far
enough that a plain 32-bit uncompressed_size with no ZIP64 field suffices.

Applications that extract archives from untrusted input are affected on Unix and
Windows targets with default features and no special configuration: upload
handling, mail-attachment processing, package and artefact ingestion, backup
restore and container-image layer extraction. No confidentiality or integrity
property is affected: there is no memory unsafety, no out-of-bounds access, no
disclosure and no data corruption.

The fix landed in zip-rs/zip2#984 and
shipped in 9.0.0.

For further details see: GHSA-q7v9-x93c-xqv3
Patched versions: [
">=9.0.0"
]
Advisory metadata: {
"aliases": [
"CVE-2026-115909",
"GHSA-q7v9-x93c-xqv3"
],
"related": [],
"collection": "crates",
"categories": [
"denial-of-service"
],
"keywords": [
"dos",
"symlink",
"unbounded-allocation",
"extract"
],
"informational": null,
"references": [],
"source": null,
"withdrawn": null,
"license": "CC0-1.0"
}

Package info: {
"name": "zip",
"version": "2.4.2",
"source": null,
"checksum": null,
"dependencies": [
{
"name": "arbitrary",
"version": "1.4.1",
"source": "registry+https://github.com/rust-lang/crates.io-index"
},
{
"name": "crc32fast",
"version": "1.4.2",
"source": "registry+https://github.com/rust-lang/crates.io-index"
},
{
"name": "crossbeam-utils",
"version": "0.8.21",
"source": "registry+https://github.com/rust-lang/crates.io-index"
},
{
"name": "displaydoc",
"version": "0.2.4",
"source": "registry+https://github.com/rust-lang/crates.io-index"
},
{
"name": "flate2",
"version": "1.1.4",
"source": "registry+https://github.com/rust-lang/crates.io-index"
},
{
"name": "indexmap",
"version": "2.14.1",
"source": "registry+https://github.com/rust-lang/crates.io-index"
},
{
"name": "memchr",
"version": "2.7.4",
"source": "registry+https://github.com/rust-lang/crates.io-index"
},
{
"name": "thiserror",
"version": "2.0.12",
"source": "registry+https://github.com/rust-lang/crates.io-index"
}
],
"replace": null
} [cargo-audit: source-test-mozlint-cargo-audit]

This review is now deprecated.

mozilla-code-review

1 issue has been found in this revision.

1 issue is located outside of the files touched by the patch:

Cargo.lock Error: Crate depends on a vulnerable version of zip.

Advisory:
zip: ZipArchive::extract aborts the process on a symlink entry with a large declared size
Package: zip
ID: RUSTSEC-2026-0429
CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Report date: 2026-10-22
ZipArchive::extract() sizes the symlink-target buffer from the uncompressed
size declared in the central directory record, before reading a single byte of
entry data:

let mut target = Vec::with_capacity(file.size() as usize);

Both inputs are attacker-controlled. ZipFile::size() returns
uncompressed_size verbatim from the central directory, widened to a full u64
by a ZIP64 extended-information extra field, and is never cross-checked against
the compressed size, the remaining archive length, or any platform-appropriate
bound for a symlink target. ZipFile::is_symlink() is decided entirely by the
S_IFLNK bit of the external-attributes field.

Vec::with_capacity() is infallible: when the reservation is refused it calls
handle_alloc_error() and aborts the process. This is not a Rust panic. It is
not caught by catch_unwind(), is unaffected by panic = "unwind", and is not
contained by running the call on a worker thread.

A 112-byte archive is sufficient. One Stored entry flagged S_IFLNK with a
ZIP64 field declaring uncompressed_size = 2^62 and a zero-byte payload makes
extract() fail with:

memory allocation of 4611686018427387904 bytes failed
Aborted (core dumped)          # exit 134

The declared value only needs to exceed the host's address space, not its RAM:
Vec::with_capacity() maps address space without touching pages, so resident
memory stays flat and the abort happens on the refused reservation itself. Under
a ulimit -v cap or a memory-constrained container the threshold drops far
enough that a plain 32-bit uncompressed_size with no ZIP64 field suffices.

Applications that extract archives from untrusted input are affected on Unix and
Windows targets with default features and no special configuration: upload
handling, mail-attachment processing, package and artefact ingestion, backup
restore and container-image layer extraction. No confidentiality or integrity
property is affected: there is no memory unsafety, no out-of-bounds access, no
disclosure and no data corruption.

The fix landed in zip-rs/zip2#984 and
shipped in 9.0.0.

For further details see: GHSA-q7v9-x93c-xqv3
Patched versions: [
">=9.0.0"
]
Advisory metadata: {
"aliases": [
"CVE-2026-115909",
"GHSA-q7v9-x93c-xqv3"
],
"related": [],
"collection": "crates",
"categories": [
"denial-of-service"
],
"keywords": [
"dos",
"symlink",
"unbounded-allocation",
"extract"
],
"informational": null,
"references": [],
"source": null,
"withdrawn": null,
"license": "CC0-1.0"
}

Package info: {
"name": "zip",
"version": "2.4.2",
"source": null,
"checksum": null,
"dependencies": [
{
"name": "arbitrary",
"version": "1.4.1",
"source": "registry+https://github.com/rust-lang/crates.io-index"
},
{
"name": "crc32fast",
"version": "1.4.2",
"source": "registry+https://github.com/rust-lang/crates.io-index"
},
{
"name": "crossbeam-utils",
"version": "0.8.21",
"source": "registry+https://github.com/rust-lang/crates.io-index"
},
{
"name": "displaydoc",
"version": "0.2.4",
"source": "registry+https://github.com/rust-lang/crates.io-index"
},
{
"name": "flate2",
"version": "1.1.4",
"source": "registry+https://github.com/rust-lang/crates.io-index"
},
{
"name": "indexmap",
"version": "2.14.1",
"source": "registry+https://github.com/rust-lang/crates.io-index"
},
{
"name": "memchr",
"version": "2.7.4",
"source": "registry+https://github.com/rust-lang/crates.io-index"
},
{
"name": "thiserror",
"version": "2.0.12",
"source": "registry+https://github.com/rust-lang/crates.io-index"
}
],
"replace": null
} [cargo-audit: source-test-mozlint-cargo-audit]

lando-worker · 2026-11-02T18:34:37Z

Pull request closed by commit 390e056

…urrent FXA server and exact URI path r=corentin,roger Pull request: #423

t-p-white requested review from corentinbect and rocketsroger October 28, 2026 14:31

t-p-white marked this pull request as ready for review October 28, 2026 14:32

lando-web Bot requested a review from a team October 28, 2026 14:32

corentinbect approved these changes Oct 28, 2026

View reviewed changes

Comment thread mobile/android/fenix/app/src/main/java/org/mozilla/fenix/IntentReceiverActivity.kt Resolved

Comment thread mobile/android/fenix/app/src/main/java/org/mozilla/fenix/IntentReceiverActivity.kt Resolved

rocketsroger reviewed Oct 28, 2026

View reviewed changes

Comment thread mobile/android/fenix/app/src/main/java/org/mozilla/fenix/IntentReceiverActivity.kt Resolved

t-p-white force-pushed the 2086039 branch from 56449b3 to 7c45293 Compare October 28, 2026 16:39

lando-web Bot requested a review from a team October 28, 2026 16:39

t-p-white added the testing-approved label Oct 28, 2026

rocketsroger approved these changes Oct 28, 2026

View reviewed changes

Comment thread mobile/android/fenix/app/src/main/java/org/mozilla/fenix/IntentReceiverActivity.kt Resolved

Comment thread mobile/android/fenix/app/src/main/java/org/mozilla/fenix/IntentReceiverActivity.kt Resolved

t-p-white force-pushed the 2086039 branch from 7c45293 to a887b14 Compare November 2, 2026 13:57

lando-web Bot requested a review from a team November 2, 2026 13:57

Bug 2086039 - Refactor isFxaPairingLink check to be scoped to the c…

3fb1d29

…urrent FXA server and exact URI path.

t-p-white force-pushed the 2086039 branch from a887b14 to 3fb1d29 Compare November 2, 2026 14:10

mozilla-code-review Bot previously requested changes Nov 2, 2026

View reviewed changes

mozilla-code-review Bot suggested changes Nov 2, 2026

View reviewed changes

rocketsroger approved these changes Nov 2, 2026

View reviewed changes

lando-worker Bot pushed a commit that referenced this pull request Nov 2, 2026

Bug 2086039 - Refactor isFxaPairingLink check to be scoped to the c…

390e056

…urrent FXA server and exact URI path r=corentin,roger Pull request: #423

lando-worker Bot closed this Nov 2, 2026

Navigation Menu

Repository navigation

Bug 2086039 - Refactor `isFxaPairingLink` check to be scoped to the current FXA server and exact URI path - #423

Bug 2086039 - Refactor `isFxaPairingLink` check to be scoped to the current FXA server and exact URI path#423
t-p-white wants to merge 1 commit into
mozilla-firefox:autolandfrom
t-p-white:2086039

t-p-white commented Oct 28, 2026 •

edited by lando-web Bot

Loading

Uh oh!

t-p-white commented Oct 28, 2026

Uh oh!

corentinbect left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

t-p-white commented Oct 28, 2026

Uh oh!

Uh oh!

Uh oh!

mozilla-code-review Bot commented Oct 28, 2026

Uh oh!

mozilla-code-review Bot commented Oct 28, 2026

Uh oh!

t-p-white commented Nov 2, 2026

Uh oh!

mozilla-code-review Bot left a comment

Uh oh!

mozilla-code-review Bot left a comment

Uh oh!

lando-worker Bot commented Nov 2, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

t-p-white commented Oct 28, 2026 • edited by lando-web Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

t-p-white commented Oct 28, 2026

Uh oh!

corentinbect left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

t-p-white commented Oct 28, 2026

Uh oh!

Uh oh!

Uh oh!

mozilla-code-review Bot commented Oct 28, 2026

Uh oh!

mozilla-code-review Bot commented Oct 28, 2026

Uh oh!

t-p-white commented Nov 2, 2026

Uh oh!

mozilla-code-review Bot left a comment

Choose a reason for hiding this comment

Uh oh!

mozilla-code-review Bot left a comment

Choose a reason for hiding this comment

Uh oh!

lando-worker Bot commented Nov 2, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

t-p-white commented Oct 28, 2026 •

edited by lando-web Bot

Loading