Envoy's overload response path must handle an already reset request

An overload mechanism is supposed to limit the work a proxy accepts, but its rejection path still has to handle the request's actual lifecycle. CVE-2024-53270 exposes a failure when Envoy tries to send an HTTP/1 overload response after the request has already reset. Istio's December 18 bulletin includes that crash among three Envoy security fixes. The faulty assumption occurs in error handling, where the request object expected by the response path may no longer exist.

The bulletin identifies affected ranges as Istio 1.22.0 through 1.22.6, 1.23.0 through 1.23.3 and 1.24.0 through 1.24.1. The 1.24.2 release implements the security update. For users who configured the overload manager through a custom EnvoyFilter, the bulletin specifically advises avoiding the http1_server_abort_dispatch load-shed point.

I view overload handling as part of the mesh's availability contract. Traffic management adds value only if its failure-control paths remain safe under the conditions they handle. A proxy needs to reject or reset work without assuming that another part of its asynchronous lifecycle has preserved the objects needed to construct a response.

Reset changes the available request state

The Envoy advisory explains that sendOverloadError assumes an active request exists when the relevant load-shed point is configured. If active_request is null, the code calls onMessageBeginImpl. That function can return an OK status directly when the stream has already reset, leaving the request pointer null.

The later path then encounters the null reference and crashes. The advisory notes that a downstream reset can occur during an HTTP/2 upstream reset. This connects the problem to a proxy handling different protocol legs and lifecycle notifications. A response-generation path cannot infer that the downstream request remains active solely because it is currently dispatching an error operation.

The important distinction is between a successful function return and the state the caller expects afterward. In the reported sequence, returning OK does not mean an active request has been created. The reset state changes what the operation does. The caller's assumption about the postcondition is therefore invalid for that lifecycle branch.

This explanation does not require treating ordinary overload responses as inherently unsafe. The affected path is selected by a named load-shed point and combined with a prior reset. The advisory's mitigation is to disable that point or use a high threshold. Istio's guidance chooses the more direct instruction to avoid that point in custom overload configurations while applying the update.

Delayed HTTP/1 reset has another set of failures

CVE-2024-53271 concerns multiple issues associated with envoy.reloadable_features.http1_balsa_delay_reset. The upstream report describes increased parsing failures after an Envoy upgrade and a reproduction involving HTTP/1.1 traffic on either side of an HTTP/2 proxy connection. It identifies connection reuse as part of the observed behavior.

The report includes HEAD requests and a server response containing 102 Processing followed by a final response. Its investigation found that disabling delayed reset, or avoiding connection reuse in the described experiment, prevented the observed request entanglement. The advisory lists disabling the runtime feature as a mitigation. These are the report's specific observations, not a claim that all informational responses fail in every configuration.

This issue differs from the overload crash. It concerns HTTP/1 parser and connection lifecycle behavior under the delayed-reset feature. The overload issue concerns generating a rejection after a reset has already invalidated an assumed request state. Both involve reset handling, but their configuration conditions and reported symptoms are not interchangeable.

The distinction is useful during diagnosis. Parsing errors on reused upstream connections point toward different evidence than a crash in overload-response generation. A release containing both fixes does not make every HTTP failure an example of both vulnerabilities. The advisory identifiers preserve those separate mechanisms.

Address sorting also needs type validation

The third flaw, CVE-2024-53269, concerns Happy Eyeballs address handling. Its Envoy advisory says the sorting algorithm can crash when additional addresses are not IP addresses. The repair validates both original and additional addresses as IP addresses before using them in that path.

Its example includes internal Envoy address representations. That matters because an endpoint description can contain a valid address representation for one purpose without satisfying the assumptions of an IP-address sorting algorithm. Validation needs to match the operation about to use the value. A general endpoint object is not proof that every contained address supports IP-specific processing.

The advisory lists disabling Happy Eyeballs or changing the address configuration as mitigations. Istio's bulletin gives this flaw a 4.5 score, separate from the higher-rated HTTP/1 issues. The common release repairs them together, but the address-validation defect has a different input and a different implementation boundary.

I find that type assumption instructive alongside the lifecycle assumptions in the other reports. Proxy code combines configuration and protocol state from several sources. The operation performing the next step still needs to establish that its input has the properties it requires. A value's presence or an earlier successful return cannot supply that guarantee by itself.

The patch also repairs deployment behavior

Istio 1.24.2 includes unrelated robustness changes. It adds DAC_OVERRIDE to the Istio CNI DaemonSet for environments with relevant files owned by non-root users. The notes explain that 1.24 removed privileged execution but also removed permissions the component still required. The release adds the narrower capability while retaining fewer privileges than the earlier privileged arrangement.

Another repair corrects RequestAuthentication handling for cross-namespace waypoint proxies. The release also fixes ambient DNS resolution for ExternalName Services. These items concern configuration and deployment behavior, not the HTTP/1 crash conditions. Keeping them separate makes the security update's scope easier to understand.

For the December vulnerabilities, the repaired proxy implementation is the essential maintenance target. Custom overload settings and runtime guards help identify the reported paths, while the advisories explain why those paths fail. The overload response must tolerate a request already reset, delayed HTTP/1 handling must preserve valid connection state, and address sorting must validate the representation it consumes before applying IP-specific logic.