Go 1.19.2 aligns proxy parsing and limits parser memory

A proxy can inspect one interpretation of a query and forward bytes that a backend interprets differently. The risk appears when a parser rejects part of an input but the original representation continues downstream unchanged. Go 1.19.2 addresses that inconsistency in ReverseProxy, alongside memory limits for tar metadata and regular-expression parsing.

The release history dates the update to 4 October 2022. The release announcement identifies three security fixes and announces the corresponding Go 1.18.7 maintenance release. Their mechanisms explain which callers are affected and why superficially valid processing can still violate an application's assumptions.

I value Go's explicit error handling, but an error is only useful when subsequent work respects what it means. A partially parsed query is a particularly clear example. Code can receive useful parsed values and an error at the same time, while another component still has access to the rejected text.

Parsing could discard a parameter that forwarding retained

The ReverseProxy issue explains that malformed query pairs are treated as a soft error. Its example includes an invalid percent escape for one key and a valid value for another. Parsing retains the valid pair while reporting the malformed escape.

That behavior is useful when a caller deliberately accepts valid fields despite an error. It becomes problematic when the caller assumes that downstream consumers will see only those accepted fields. Forwarding the unchanged raw query preserves text that the local parse rejected.

The issue also connects the problem to semicolon handling. Go 1.17 changed query parsing to reject keys containing semicolons. A backend that still treats semicolons as separators can derive a different set of parameters from the original bytes. The disagreement creates an opportunity for parameter smuggling across the proxy boundary.

The important relationship is between inspection and forwarding. If a proxy makes a policy decision using parsed parameters, the backend should not acquire additional effective parameters from text that the proxy discarded. A shared transport does not establish that the two parsers agree about malformed syntax.

The correction is conditional on parsed state

The Go 1.19.2 proxy implementation calls Director and then checks whether the outbound request's Form field is non-nil. When it is, the proxy cleans the outgoing raw query. The announcement describes this as the indication that the proxy has parsed the query parameters.

Proxies that have not parsed the parameters continue forwarding the original query unchanged. This preserves an important distinction in the contract. A generic forwarding proxy and a proxy that interprets query values are performing different work. The fix targets the mismatch introduced when local interpretation occurs before forwarding.

That also gives maintainers a concrete way to understand the change. Reading the proxy's Director and the handling of Form is more informative than searching only for a ReverseProxy constructor. The relevant state exists after Director returns, so any explanation needs to follow that ordering.

My preference is for a security account to retain conditions like this one. Saying that ReverseProxy now removes every malformed parameter would misdescribe the release. The correction depends on the parsed state of the outbound request, which is the connection between the proxy's interpretation and its forwarding behavior.

Tar metadata needed its own allocation bound

The tar issue, CVE-2022-2879, describes unbounded allocation while reading file headers. The new limit is one MiB for the relevant header blocks. A malicious archive could otherwise cause memory exhaustion or a panic through metadata processing.

The released tar reader shows a bounded helper for special files. It reads through a limiting reader that permits one byte beyond the maximum, then returns ErrFieldTooLong if that extra byte is present. Reading one byte beyond the allowance distinguishes an exactly permitted record from an oversized one.

This is a different limit from a restriction on extracted file contents. An archive consumer can spend memory interpreting metadata before it reaches ordinary payload processing. The allocation boundary therefore needs to exist at the point where that metadata is read into memory.

The implementation also makes rejection observable as a parsing error. That gives callers a result they can handle within their archive-processing policy. A process-wide memory ceiling does not supply the same behavior. It can terminate the entire process after an oversized allocation instead of identifying the archive record that exceeded its allowance.

Linear growth still had an expensive multiplier

The regexp/syntax issue, CVE-2022-41715, identifies memory growth in parsing expressions. The report says the representation is linear in input size, but its multiplier can reach 40,000. A complexity class alone therefore does not establish a reasonable memory budget for a relatively small expression.

The announcement describes a 256 MB footprint limit for a parsed expression. The released parser source makes the accounting more specific. It has separate limits for compiled instructions and runes in expression trees, with comments explaining character-class expansion and repeated use of Unicode classes.

That detail matters because a short textual construct can expand into a larger internal representation. Counting only the expression's source bytes misses the cost of those structures. The parser needs accounting aligned with what it allocates and what the compiled representation will require. Limits on those representations address the allocation directly during expression processing.

I regard the distinction between complexity and budget as the useful lesson in this fix. Linear growth can still exceed a service's resources when the multiplier is large. October's changes put checks at the interpretation boundaries where the additional work becomes concrete, while the proxy change preserves the relationship between an interpreted query and the request sent onward.