vendor: github.com/moby/spdystream v0.5.1#3805
vendor: github.com/moby/spdystream v0.5.1#3805thaJeztah wants to merge 1 commit intodocker:masterfrom
Conversation
Fix memory amplification in SPDY frame parsing leads to denial of service ([CVE-2026-35469] / [GHSA-pc3f-x583-g7j2]) full diff: moby/spdystream@v0.5.0...v0.5.1 [CVE-2026-35469]: GHSA-pc3f-x583-g7j2 [GHSA-pc3f-x583-g7j2]: GHSA-pc3f-x583-g7j2 Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
| github.com/moby/locker v1.0.1 // indirect | ||
| github.com/moby/patternmatcher v0.6.1 // indirect | ||
| github.com/moby/spdystream v0.5.0 // indirect | ||
| github.com/moby/spdystream v0.5.1 // indirect |
There was a problem hiding this comment.
github.com/moby/spdystream is coming from our direct Kubernetes deps, not from a standalone path in buildx. In this repo the relevant direct modules are k8s.io/api, k8s.io/apimachinery, and k8s.io/client-go, and the runtime path is the Kubernetes exec/SPDY code used by the kubernetes driver.
I checked the module graph and v0.35.2 of k8s.io/apimachinery and k8s.io/client-go still pull github.com/moby/spdystream v0.5.0. Upstream Kubernetes picks up github.com/moby/spdystream v0.5.1 in v0.35.4.
Given that, I think the cleaner change here is to update the aligned Kubernetes deps first (k8s.io/api, k8s.io/apimachinery, k8s.io/client-go) instead of bumping and vendoring spdystream directly. That keeps the fix at the owning layer and reduces the chance of regressions from drifting away from the upstream-tested combination.
Opened #3808
There was a problem hiding this comment.
Right, but technically not strictly needed; go modules use MVS for a reason; consumers can decide to use a SemVer-compatible higher version of the dependency, and (e.g.) kubernetes defines the minimum required version.
There was a problem hiding this comment.
Fair point on MVS, agreed that this is technically valid.
My concern was less about module resolution and more about vendoring. Since we vendor the sources here, bumping github.com/moby/spdystream directly means we carry a combination that is slightly ahead of the k8s.io/* release line we currently depend on.
There was a problem hiding this comment.
Yeah, it wasn't a bad one this time, but I'm always cautious updating k8s.io/xxxx deps, as they tend to bring in the whole world of updates 😂
2 participants
Fix memory amplification in SPDY frame parsing leads to denial of service (CVE-2026-35469 / GHSA-pc3f-x583-g7j2)
full diff: moby/spdystream@v0.5.0...v0.5.1