Bug 2050875 - Use exhaustive whens for Shake to Summarize feature#307
Bug 2050875 - Use exhaustive whens for Shake to Summarize feature#307nicholaspoon03 wants to merge 1 commit into
Conversation
|
View this pull request in Lando to land it once approved. |
|
No new issues detected. This pull request is 🆗 |
MatthewTighe
left a comment
There was a problem hiding this comment.
this has been on my wishlist, thanks for taking care of it!
7f65648 to
d301517
Compare
|
rebased and updated try |
|
Pull request closed by commit 6a4188b |
…att-tighe Pull request: #307
There was a problem hiding this comment.
2 issues have been found in this revision.
2 issues are located outside of the patch:
Cargo.lock:NoneError: Crate depends on a vulnerable version of quick-xml.
Advisory:
Unbounded namespace-declaration allocation in NsReader enables memory-exhaustion denial of service
Package: quick-xml
ID: RUSTSEC-2026-0195
CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Report date: 2026-06-29
NsReader resolves namespaces by calling NamespaceResolver::push for every
Start/Empty event before the event is returned to the caller. push
iterated all xmlns / xmlns:* attributes on the start tag and, for each one,
appended the prefix bytes to an internal buffer and pushed a NamespaceBinding
(32 bytes on 64-bit) to an internal Vec, with no upper bound on the number of
declarations.
Impact
A start tag with N namespace declarations drove roughly 3× the tag's byte
size in NamespaceResolver heap, allocated inside quick-xml before the
NsReader consumer ever received the event and could inspect or reject it. A
consumer that bounds its input size therefore still cannot bound this
allocation: an M-byte start tag yields on the order of 3 × M bytes of
resolver heap the caller never sees.
On untrusted XML this lets a remote, unauthenticated attacker force large heap
allocations with a single start tag. With several NsReaders running
concurrently on independent inputs (a common server pattern), the allocations
stack and can exhaust process memory, causing the operating system to kill the
process (OOM). This was confirmed against a real-world RPKI relying party (NLnet
Labs Routinator), where concurrent RRDP validation workers parsing a crafted
snapshot.xml exceeded the memory limit and the process was OOM-killed.
Affected code paths
Consumers using NsReader (which always calls NamespaceResolver::push before
yielding Start/Empty), or calling NamespaceResolver::push directly. A plain
Reader that does not perform namespace resolution is not affected.
Remediation
Upgrade to quick-xml >= 0.41.0. NamespaceResolver::push now rejects a start
tag that declares more than DEFAULT_MAX_DECLARATIONS_PER_ELEMENT (256)
namespace bindings, returning the new NamespaceError::TooManyDeclarations
instead of allocating without limit. The limit is configurable via
NamespaceResolver::set_max_declarations_per_element (use usize::MAX to
restore the previous unbounded behavior), and NsReader::resolver_mut() is
provided to reach it.
There is no clean workaround for NsReader consumers before 0.41.0, as the
allocation happens inside the reader with no configuration knob to cap it.
URL: tafia/quick-xml#970
Patched versions: [
">=0.41.0"
]
Advisory metadata: {
"aliases": [],
"related": [],
"collection": "crates",
"categories": [
"denial-of-service"
],
"keywords": [
"xml",
"parser",
"dos",
"memory",
"namespace"
],
"informational": null,
"references": [
"https://github.com/tafia/quick-xml/commit/7ca25266e94987210daa864889ab15c9332c8a2a"
],
"source": null,
"withdrawn": null,
"license": "CC0-1.0"
}
Package info: {
"name": "quick-xml",
"version": "0.37.5",
"source": "registry+https://github.com/rust-lang/crates.io-index",
"checksum": "331e97a1af0bf59823e6eadffe373d7b27f485be8748f71471c662c1f269b7fb",
"dependencies": [
{
"name": "memchr",
"version": "2.7.4",
"source": "registry+https://github.com/rust-lang/crates.io-index"
}
],
"replace": null
} [cargo-audit: source-test-mozlint-cargo-audit]
Cargo.lock:NoneError: Crate depends on a vulnerable version of quick-xml.
Advisory:
Quadratic run time when checking a start tag for duplicate attribute names
Package: quick-xml
ID: RUSTSEC-2026-0194
CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Report date: 2026-06-29
BytesStart::attributes() returns an Attributes iterator which, by default
(with_checks(true)), rejects a start tag that repeats an attribute name. For
each attribute yielded, the iterator compared the new name against every name
seen so far in the same tag using a linear scan, so a start tag with N
distinct attribute names cost O(N²) byte comparisons. There was no bound on
N other than the size of the buffered start tag.
Impact
Any code that parses untrusted XML and iterates a start tag's attributes with
the default duplicate check enabled can be made to spend CPU time quadratic in
the number of attributes on a single tag. Because the check is pure computation
with no .await/I/O, an I/O-based timeout on the consumer (for example a read
or request timeout) cannot interrupt it while it runs.
Measured cost of a single start tag, release build:
| Attributes on one tag | Time |
|---|---|
| 80,000 | ~6 s |
| 800,000 | ~10 min |
The cost grows with the square of the attribute count, so a start tag of a few
tens of megabytes can stall a parsing thread for hours. No memory is exhausted
and the parser does not crash; the effect is CPU exhaustion on the thread doing
the parsing: a single crafted start tag can pin a CPU core for minutes to hours,
denying service to that worker. A deployment that places a wall-clock bound on
parsing, or confines it to a non-critical thread, may consider the availability
impact lower.
Affected code paths
BytesStart::attributes()/Attributesiterated with checks enabled (the
default), andBytesStart::try_get_attribute.NsReader, which resolves namespaces by iterating a tag's attributes and so
reaches the same check internally.
Consumers that iterate attributes with .attributes().with_checks(false) and do
not use NsReader are not affected.
This was reported as reachable by a remote, unauthenticated attacker in a
real-world RPKI relying party (NLnet Labs Routinator) via a crafted RRDP
snapshot.xml.
Remediation
Upgrade to quick-xml >= 0.41.0, where the duplicate check keeps the linear
scan for start tags with a small number of attributes and switches to an O(1)
hash pre-filter above a threshold, making the whole tag O(N). The reported
AttrError::Duplicated positions are unchanged.
If upgrading is not possible and duplicate-name detection is not required,
disable it with .attributes().with_checks(false) (this does not help
NsReader consumers, which have no equivalent opt-out before 0.41.0).
URL: tafia/quick-xml#969
Patched versions: [
">=0.41.0"
]
Advisory metadata: {
"aliases": [],
"related": [],
"collection": "crates",
"categories": [
"denial-of-service"
],
"keywords": [
"xml",
"parser",
"dos",
"algorithmic-complexity",
"quadratic"
],
"informational": null,
"references": [
"https://github.com/tafia/quick-xml/pull/971",
"https://github.com/tafia/quick-xml/commit/07f3db8343cf152f5bc3483ef5b3164582489bea"
],
"source": null,
"withdrawn": null,
"license": "CC0-1.0"
}
Package info: {
"name": "quick-xml",
"version": "0.37.5",
"source": "registry+https://github.com/rust-lang/crates.io-index",
"checksum": "331e97a1af0bf59823e6eadffe373d7b27f485be8748f71471c662c1f269b7fb",
"dependencies": [
{
"name": "memchr",
"version": "2.7.4",
"source": "registry+https://github.com/rust-lang/crates.io-index"
}
],
"replace": null
} [cargo-audit: source-test-mozlint-cargo-audit]
No description provided.