common/srs: avoid pre-allocating untrusted lengths in the rule-set reader - #4399
Open
AlexandrKhromov2005 wants to merge 224 commits into
Open
common/srs: avoid pre-allocating untrusted lengths in the rule-set reader#4399AlexandrKhromov2005 wants to merge 224 commits into
AlexandrKhromov2005 wants to merge 224 commits into
Conversation
`SecTrustEvaluateWithError` is serial
This reverts commit 62cb06c.
Recent Windows 11 builds remove TCP estats, which made writeAndWaitAck return without waiting for acknowledgment. sing now queries SIO_TCP_INFO on the socket instead, and falls back to estats on systems predating it (Windows 10 1703).
Batched darwin packet I/O now also covers connected sockets on iOS.
CI took the library from the head of refs/heads/go. The packages carried a library that differs from the bindings in the binary. CI reads the library file from the commit in CRONET_GO_VERSION, and the update script points that pin at the generated branch.
…ader The binary rule-set (.srs) reader repeatedly reads a length via binary.ReadUvarint and then immediately allocates a slice of that size (make([]T, length)) before reading the elements. The length is untrusted, so a crafted rule-set can declare a huge count and either OOM the process on the allocation or panic with "makeslice: len out of range". Read incrementally instead: - element slices grow via append with a capped initial capacity, so a bogus length simply hits EOF while reading the elements; - byte slices are read through a small readBytes helper backed by io.CopyN, which grows the buffer only as bytes actually arrive. Also add FuzzSRSRead covering srs.Read. Covers: Read, readRuleItemString, readRuleItemUint8, readRuleItemUint16, readLogicalRule, readPrefix (ip_cidr) and readIPSet (ip_set).
nekohasekai
force-pushed
the
testing
branch
5 times, most recently
from
August 9, 2026 06:58
9b20d01 to
426c5fa
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
common/srs: avoid pre-allocating untrusted lengths in the rule-set reader
The binary rule-set (
.srs) reader repeatedly reads a length withbinary.ReadUvarintand immediately allocates a slice of that size(
make([]T, length)) before reading the elements. The length comes from the(untrusted) rule-set data, so a crafted
.srscan declare an enormous count andeither OOM the process on the allocation or panic with
makeslice: len out of range. This is reachable when parsing rule-set content,including remote rule-sets (
route/rule/rule_set_remote.gocallssrs.Read(..., false)on downloaded content).Found by fuzzing (
go test -fuzz); a ~40-byte input is enough to trigger it.Fix
Read incrementally instead of trusting the length for a single allocation:
appendwith a capped initial capacity, so a boguslength simply hits EOF while reading the elements;
readByteshelper backed byio.CopyN, whichgrows the buffer only as bytes actually arrive.
Covers
Read,readRuleItemString,readRuleItemUint8,readRuleItemUint16,readLogicalRule,readPrefixandreadIPSet. AddsFuzzSRSRead. Existingtests pass; valid rule-sets still decode.
Note: the same "read length, then
make" pattern also exists in thesuccinct-set reader used for AdGuard-format domains
(
sing/common/domain/set.go), reached from.srsvia AdGuard domain items;that lives in the
sagernet/singdependency and would need the same treatmentthere. Happy to follow up.