Envoy CVE-2026-48521 深度解析上游 HTTP/3 经 ALPN 自动协商时的空指针崩溃【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoyEnvoy 修复了 CVE-2026-48521当集群配置为auto_config基于 ALPN 与上游自动协商协议、且上游通过 HTTP/3 应答时进程会因空指针解引用而异常终止。这不是优雅退出而是整个代理实例崩溃所有在途连接被瞬间切断。受影响的是启用AutoHttpConfig且声明了http3_protocol_options的上游集群。本文基于仓库 changelog、架构文档与核心源码还原这条从配置到崩溃的调用链锁定最可能的空指针风险点并给出可落地的配置与自查清单。1技术前置读本文前需要搞懂的 3 个概念ALPN 自动协商AutoHttpConfigALPNApplication-Layer Protocol Negotiation是 TLS 握手期间双方交换我支持哪些协议清单的机制。Envoy 的auto_config分支语义是具体用 HTTP/1 还是 HTTP/2由与上游的 ALPN 协商结果决定默认 ALPN 列表为h2,http/1.1见 http_protocol_options.proto L102-L122。关键点是 HTTP/3 是条件性协议——只有配置里声明了http3_protocol_options且上游有明确通告时才启用。这个条件性正是崩溃土壤。HTTP/3 通告Alt-Svc与通告缓存上游是否支持 HTTP/3 由 Alt-Svc 响应头RFC 7838或 HTTPS DNS 资源记录通告Envoy 把这些通告存在HttpServerPropertiesCachealternate protocols cache里当前只记录同主机名同端口的条目。没有通告就只走 TCP 协议有通告才尝试 QUIC。ConnectivityGrid的几乎所有决策试不试 HTTP/3、记不记失败都要先查这个缓存缓存引用一旦为空后续所有访问都是雷。双池竞速与 HTTP/3 失败记忆http3_upstream.md 描述的ConnectivityGrid同时包装一个 QUIC 池和一个 TCP 混合池HTTP/3 已通告且健康时请求先走 QUIC 池300ms 内没成功就并行打到 TCP 池谁先成功谁胜出。同时因为网络设备常拦截 UDPEnvoy 需要记住哪些上游的 HTTP/3 持续失败状态机Pending/Broken/FailedRecently/Confirmed退避期内直接跳过 HTTP/3。探测、竞速、回退、记忆四套机制叠加引入了大量惰性创建的对象和异步回调——任何一处时序没对齐就可能解引用空指针。理解了协商语义和缓存的角色接下来看一条请求如何在代码里一步步走向崩溃。2崩溃链路重建从配置加载到进程终止以下调用链基于 conn_pool_grid.cc 的实际代码路径重建。Step 1配置入口。集群typed_extension_protocol_options里声明auto_confighttp3_protocol_options。配置工厂强制校验auto_config启用 HTTP/3 时必须同时给出alternate_protocols_cache_options否则直接报alternate protocols cache must be configured when HTTP/3 is enabled with auto_configconfig.cc L92-L98。校验通过ConnectivityGrid被构造构造函数对缓存只有一句ASSERT(alternate_protocols)conn_pool_grid.cc L349——注意ASSERT在 release 构建中被编译移除。Step 2请求进入网格。ConnectivityGrid::newStream()L441-L501第一行就调用getOrCreateHttp3Pool()L450。QUIC 池是惰性创建的http3_pool_为空时才走createHttp3Pool()L392-L401http2_pool_、http3_alternate_pool_同理L381-L390、L403-L413。Step 3判断是否尝试 HTTP/3。shouldAttemptHttp3()L568-L612用alternate_protocols_-findAlternatives(origin_)查通告缓存有 h3 通告、未标记 broken、ALPN 能解析出 QUIC 版本才返回 true。这里已经第一次解引用alternate_protocols_。Step 4访问状态追踪器。shouldAttemptHttp3() options.can_use_http3_成立后L454-L466 连续调用getHttp3StatusTracker()L529-L532其内部执行alternate_protocols_-getOrCreateHttp3StatusTracker(origin_)并直接取返回值上的成员。若alternate_protocols_为空这里就是空指针解引用debug 下 L349 的ASSERT能拦住release 下进程直接终止。Step 5竞速与回调链。请求挂在WrapperCallbacks上next_attempt_timer_300mskDefaultTimeoutMsL28到期触发onNextAttemptTimer()L299-L307可能同时发起 happy-eyeballs 备选 QUIC 地址连接。任何池失败都会走ConnectionAttemptCallbacks::onPoolFailure → onConnectionAttemptFailed()L136-L181从connection_attempts_摘除失败尝试、判断是否只剩 TCP 池、必要时tryAnotherConnection()创建 HTTP/2 池。L146 直接执行host-hostname()打日志——失败回调携带的host参数在该路径上没有判空同函数 L142 对另一条分支却做了host ! nullptr检查。Step 6标记 broken 与终止。TCP 成功而 HTTP/3 失败时maybeMarkHttp3Broken()L263-L268→markHttp3Broken()L539-L543再次解引用alternate_protocols_。时序上QUIC 池创建中的异步回调先于缓存/追踪器就绪执行或网格析构~ConnectivityGridL358-L371 置destroying_并逐个signalFailureAndDeleteSelf与在途回调交错都是触发解引用的窗口。3源码级根因锁定官方 changelog 只声明修复了异常进程终止未披露具体修复 diff当前仓库快照中该修复仅体现为 http3__fixed-crash-due-to-null-deref.rst 一条记录。以下为基于代码结构的合理推断非官方修复细节。三个最可能的空指针/异常访问点风险点位置为什么这里会空状态追踪器解引用conn_pool_grid.cc L454-L466 → L529-L532getHttp3StatusTracker()无条件解引用alternate_protocols_构造函数 L349 只有ASSERTrelease 构建下为空缓存直接崩溃失败回调路径conn_pool_grid.cc L136-L181onConnectionAttemptFailedL146 解引用host-hostname()无判空deferredDelete摘链与后续回调交错时attempt指向的池成员可能已被析构broken 标记路径conn_pool_grid.cc L539-L543markHttp3Broken()对alternate_protocols_二次解引用与 Step 4 同根但发生在竞速收尾、距析构最近的时刻另有一处值得运维注意的文档与源码不一致架构文档描述 broken 退避为首次 5 分钟、翻倍、上限 1 天但 http3_status_tracker_impl.cc L8-L11 实际是初始 1 秒DefaultExpirationTime{1}、按1 consecutive_broken_count_指数翻倍、上限MaxConsecutiveBrokenCount 17即 2^17 ≈ 36 小时项目架构文档描述源码实际值初始损坏期5 分钟1 秒L9退避翻倍上限1 天2^17 秒 ≈ 36 小时L11排障时若按文档预期观察5 分钟内不重试 HTTP/3会被实际行为误导。4修复验证测试用例即证据回归测试是确认修复行为的两层基线ConnectivityGridTest.Successconn_pool_grid_test.cc L286-L304验证有 h3 通告 →newStream惰性创建 QUIC 池 →onHandshakeComplete标记Confirmed→onPoolReady回传调用方的完整正向路径ConnectivityGridTest.DoubleFailureThenSuccessSerial同文件 L323-L357验证核心降级链——HTTP/3 池失败不上抛 → 备选池失败 → HTTP/2 池成功 → 最终isHttp3Broken()为真。断言里pool_failure_在回退期间被调用 0 次正是不崩溃、优雅降级的直接证据MarkBrokenWithBackoff/MarkBrokenWithBackoffMaxhttp3_status_tracker_impl_test.cc L67-L99、L101-L124断言损坏期 1s → 2s → 4s → 8s 指数递增并在 17 次后封顶 2^17 秒锁定第 3 节表格中源码实际值的准确性。本地复现需要 Bazel 构建环境bazel test //test/common/http:conn_pool_grid_test bazel test //test/common/http:http3_status_tracker_impl_test5生产落地auto_config HTTP/3 上游配置与自查清单完整可运行的最小配置集群 传输层 过滤器static_resources: listeners: - name: listener_0 address: socket_address: { address: 0.0.0.0, port_value: 10000 } filter_chains: - filters: - name: envoy.filters.network.http_connection_manager typed_config: type: type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager http_filters: - name: envoy.filters.http.alternate_protocols_cache typed_config: type: type.googleapis.com/envoy.extensions.filters.http.alternate_protocols_cache.v3.FilterConfig - name: envoy.filters.http.router typed_config: type: type.googleapis.com/envoy.extensions.filters.http.router.v3.Router route_config: virtual_hosts: - name: host domains: [*] routes: - match: { prefix: / } route: { cluster: upstream_with_h3 } clusters: - name: upstream_with_h3 connect_timeout: 5s type: STRICT_DNS load_assignment: cluster_name: upstream_with_h3 endpoints: - lb_endpoints: - endpoint: address: socket_address: address: upstream.example.com port_value: 443 transport_socket: name: envoy.transport_sockets.tls typed_config: type: type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext sni: upstream.example.com typed_extension_protocol_options: envoy.extensions.upstreams.http.v3.HttpProtocolOptions: type: type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions auto_config: http_protocol_options: {} http2_protocol_options: {} http3_protocol_options: {} alternate_protocols_cache_options: name: default_alternate_protocols_cache max_entries: 1024踩坑提醒auto_config下http_protocol_options、http2_protocol_options、http3_protocol_options三个字段缺一不可缓存字段在启用 HTTP/3 时为强制项config.cc L92-L98 校验http3_protocol_options只是允许实际启用仍取决于上游 Alt-Svc 通告没通告就走 TCPauto_config依赖 ALPNtransport_socket必须是支持 ALPN 的 TLS 套接字否则配置加载失败alternate_protocols_cache_options.name是缓存实例标识同名缓存在多处引用时字段必须完全一致启用key_value_store_config持久化时 Envoy 并发度必须为 1否则同样报配置错误。运维自查 Checklist可直接复制到工单✅ Envoy 版本已升级到包含http3__fixed-crash-due-to-null-deref.rst条目的发布在changelogs/current/bug_fixes/或已发布版本的 changelog 目录中确认该条目✅ 所有使用auto_config HTTP/3 的集群均已声明alternate_protocols_cache_options✅ HCM 过滤器链中启用envoy.filters.http.alternate_protocols_cache✅ 上游网络是否拦截 UDP 已确认若拦截确认依赖状态追踪器退避回退 TCP初始仅 1 秒排障时勿按文档5 分钟预期✅ 观察upstream_http3_broken统计项增长确认 broken 标记链路工作正常✅ 升级后以conn_pool_grid_test与http3_status_tracker_impl_test为基线跑过回归升级建议只有一条升级到包含该修复的版本。确认方法很简单——拉取对应 tag 后查看changelogs/下是否存在该 bug_fixes 条目。配置加载后可通过 admin 接口的/config_dump核对实际生效的auto_config与缓存配置并用/stats观察upstream_http3_broken计数。6仓库证据索引修复条目changelogs/current/bug_fixes/http3__fixed-crash-due-to-null-deref.rst架构文档source/docs/http3_upstream.md协议定义api/envoy/extensions/upstreams/http/v3/http_protocol_options.proto核心实现source/common/http/conn_pool_grid.cc核心实现source/common/http/http3_status_tracker_impl.cc核心实现source/common/http/http_server_properties_cache_impl.cc配置校验source/extensions/upstreams/http/config.cc测试用例test/common/http/conn_pool_grid_test.cc测试用例test/common/http/http3_status_tracker_impl_test.cc【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考