[mcr25.0] Bump six Go modules to fix eight CVEs

[dperny]

Six Go module requirements move, each by go mod edit -require then go mod tidy and go mod vendor: github.com/docker/docker v24.0.5+incompatible to v24.0.9+incompatible for CVE-2024-24557 (GO-2024-2512); github.com/opencontainers/runc v1.1.12 to v1.2.8 for CVE-2025-31133, CVE-2025-52565 and CVE-2025-52881 (GO-2025-4096, GO-2025-4097, GO-2025-4098); google.golang.org/grpc v1.80.0 to v1.83.1 for CVE-2026-84304 (GHSA-vp52-pcj8-j9qc; the Go vulnerability database has no entry for it); and one commit taking golang.org/x/crypto v0.53.0 to v0.55.0, golang.org/x/net v0.55.0 to v0.57.0 and golang.org/x/text v0.38.0 to v0.41.0 for CVE-2026-56854, CVE-2026-46600 and CVE-2026-56852 (GO-2026-6303, GO-2026-5942, GO-2026-5970) — x/net and x/text land a minor above the v0.56.0 and v0.39.0 that fix them, because x/crypto v0.55.0 requires those. buildx builds with -mod=vendor, so the vendor tree moves with the manifest, and no file buildx itself authors changed.

The runc 1.1 to 1.2 and grpc 1.80 to 1.83 moves cross release lines, and grpc v1.83.1 in turn forces go.opentelemetry.io/otel and otel/trace to v1.44.0 and otelhttp to v0.61.0.

go build -mod=vendor ./... and the unit suite pass and re-vendoring is a no-op. The Makefile's test, lint and validate targets all run through docker buildx bake and no Docker daemon was available, so none of them ran.

Left alone: CVE-2024-41110 and CVE-2025-15558, major-line crossings triage escalated; four more docker/docker findings with no fixed version; the standard-library findings, which are toolchain moves. And x/crypto stops at v0.55.0 while golang.org/x/crypto/ssh is vendored here, so GO-2026-6354 (CVE-2026-78662) and GO-2026-6355 (CVE-2026-56855) still stand — 41 advisories remain in total on the internal review's own scan.

The head branch is on the fork dperny/buildx rather than on this repository.

Internal review: round 1, verdict approve, by the Warlock CVE Reviewer.

Release lines crossed, as authorized by triage:

• github.com/opencontainers/runc v1.1.12 → v1.2.8 (for CVE-2025-31133, CVE-2025-52565, CVE-2025-52881): Advance the module to v1.2.8, which is the smallest move that carries the fix, and do not carry it as a patch. buildx compiles exactly one package of runc — libcontainer/user, and only transitively, through github.com/docker/docker/pkg/idtools — and at v1.2.8 that package still exists as a deprecated alias of github.com/moby/sys/user that re-exports every symbol the vendored idtools actually uses: LookupUser, LookupUid, LookupGroup, LookupGid, ParsePasswd, ParseGroup, the User, Group, SubID and IDMap types, and the sub-uid and sub-gid readers. So the crossing from the 1.1 line to the 1.2 line costs this repository one new indirect module, github.com/moby/sys/user v0.3.0, and nothing else; that was established rather than assumed by building every package off this commit in a scratch copy with only the runc requirement changed. runc 1.2.0's breaking changes are all in the container runtime runc ships and none of it is linked into this plugin, which compiles no libcontainer runtime code: bind-mount option handling now errors instead of silently ignoring superblock flags, EnterPid and the {Pre,Post}MountCmds hooks were removed, --criu and runc kill -a were deprecated, and tun/tap devices left the default device allowlist. The one mechanical factor the policy insists on is satisfied — runc 1.2.0 raised its minimum Go to 1.20 and this tree's go.mod already declares go 1.25.0, so no toolchain move and no Fipster propagation follows. Carrying the fix ourselves is the worse trade and is barely available: runc's release policy supports only the latest release and the two before it, so the 1.1 line this tree sits on is past the end of support and received no fix for any of these three container-escape CVEs — the first fix event for all three is 1.2.8 — and buildx has no documented way to carry a vendor patch (no .warlock/workflow/SKILL.md in the checkout, no workflow skill staged for this repository), so a backport would be an undocumented patch, rebased indefinitely at every future base move, against runtime code this plugin does not execute. The horizon belongs in this decision: 1.2 is today runc's latest-2, which under that policy receives high-severity security fixes only and will fall out of support when the next minor ships, so v1.2.8 is deliberately the minimal move that ends the finding rather than a destination that never has to be revisited — going further, to 1.3.3 or the 1.4 line, is a larger crossing that nothing in this work item requires.
• google.golang.org/grpc v1.80.0 → v1.83.1 (for CVE-2026-84304): Advance the module to v1.83.1. The affected range has no earlier fix event, so no version on the 1.80 line carries the fix and the minimum move is three minors; the alternative of carrying it ourselves is worse on every count. What advancing brings with it was read rather than sampled: across grpc-go 1.81.0, 1.82.0 and 1.83.0 the delta is dependency and telemetry work plus xDS features that are experimental or off by default — SNI and SAN validation behind GRPC_EXPERIMENTAL_XDS_SNI, GCP authentication and HTTP CONNECT proxy support, ring-hash endpoint keys, per-call metric labels and buffer-pool work — and the behaviour changes that could reach a consumer are narrow and enumerable: strict gRPC path validation is now mandatory because GRPC_GO_EXPERIMENTAL_DISABLE_STRICT_PATH_CHECKING was removed, the load-balancing policy registry became case-sensitive, and the deprecated gzip compressor now enforces MaxRecvMsgSize on decompressed buffers. None of that lands on this repository. buildx uses grpc as the transport for BuildKit sessions and its own controller, over generated service stubs with conventional /Service/Method paths, and registers no custom load-balancing policy or compressor; the vendored surface is 65 grpc packages of client, transport and balancer plumbing with no xDS tree at all. The whole delta compiles: building every package off this commit in a scratch copy with only the grpc requirement raised succeeds with no other go.mod change. The mechanical factor the policy refuses to let a scope judgement overrule is satisfied — 1.81.0 raised grpc's minimum Go to 1.25 and this tree's go.mod already declares go 1.25.0, so no toolchain move follows and no Fipster propagation chain is opened. Against that, backporting is a poor plan even though the commits are identifiable (grpc-go 7354d9c8debb4bcf2225bf429857078de310c176 and 8cfeca0e1ee5ea0980dcc320e20240fa1079ec77): the fix is a receive-buffer compaction rework of internal/transport, which is squarely on the plugin's network path, buildx has no documented way to carry a vendor patch at all — no .warlock/workflow/SKILL.md in the checkout and no workflow skill staged for this repository — and a hand-carried transport change would need rebasing at every future grpc move. Advancing is both the cheaper and the better-supported route.

Not verified by the internal review:

• record-accuracy — concern: The record is unusually accurate on everything load-bearing, and it volunteers the two things a careless account would have buried -- the version over-shoot and the two dispositions whose cost claims this tree contradicts. Its arithmetic checks out too: 50 to 41 with nine gone is right when counted by advisory id, which is how it counted. One material gap, filed as rf-1: out_of_scope names three residual advisories 'not in this work item' and reads as the complete set, and it is not -- 41 remain, and the omissions include two further x/crypto/ssh advisories fixed at x/crypto v0.56.0, one minor above where this change lands, in the same package as the CVE that unit fixes. A smaller asymmetry worth noting rather than filing: the x unit's detail says explicitly that crypto/ssh and text/unicode/norm are vendored but does not say that x/net/dns/dnsmessage is not, which could leave a reader thinking the vulnerable DNS parser shipped. The disposition record covers that fully and the record's not_verified entry on reachability is candid about not re-litigating it.
• collateral-version-advancement — concern: Four moves were weighed by no disposition: go.opentelemetry.io/otel and otel/trace, both direct requirements, v1.43.0 to v1.44.0; otelhttp v0.48.0 to v0.61.0, thirteen 0.x minors; github.com/moby/sys/mountinfo v0.6.2 to v0.7.1 and github.com/containerd/console v1.0.3 to v1.0.5. All are forced by the dispositioned targets, as the targets' own go.mod files show, so none is a choice the Remediator made. The positive evidence I could gather is good as far as it goes. otel v1.44.0's single breaking change is a default cardinality limit in go.opentelemetry.io/otel/sdk/metric, and sdk/metric is not vendored here at all, so it cannot reach this build; buildx's own code imports only otel, otel/trace and otel/attribute, the stable 1.x surface; every one of the eleven release platforms compiles, including ./... for darwin/arm64 and windows/amd64; the unit suite passes; and my own scan shows no new advisory. What remains genuinely unweighed is otelhttp: v0.61.0 carries the HTTP semantic-convention migration, so the attribute names on outbound traces made through buildkit's tracing transport will differ from v0.48.0's, and the contrib set is now split -- otelgrpc and otelhttptrace stay at v0.48.0 against otel v1.44.0, relying on otel's 1.x compatibility promise. Nothing here exercised tracing or OTLP export. This is filed as rf-2, advisory rather than blocking, because it is a Triager judgement and there is no action available to the Remediator that removes it short of a forbidden replace directive or leaving CVE-2026-84304 unfixed.
• disposition-cost-claims — concern: Three statements in the disposition records are contradicted by this tree, all of them confirmed by me independently rather than taken from the change record's notes. The runc block says the crossing 'costs this repository one new indirect module, github.com/moby/sys/user v0.3.0, and nothing else'; runc v1.2.8 also forces containerd/console and moby/sys/mountinfo up, and both are direct requirements of buildx. The grpc block says raising only the grpc requirement 'succeeds with no other go.mod change'; it forces seven further modules. And the CVE-2026-46600 disposition records a build trial that raised x/net to v0.56.0, x/text to v0.39.0 and x/crypto to v0.55.0 together, a combination minimal version selection cannot produce, since x/crypto v0.55.0 requires x/net v0.57.0 and x/text v0.41.0. In every case the decision the Triager reached still looks right -- no fix exists lower for any of them and buildx has no documented way to carry a vendor patch -- but the cost each was weighed against was not the real cost, and the build trials appear not to have been run as described. Filed as rf-3 for a Triager revisit; advisory because it does not change what this diff should be.
• repository-build-and-lint-pipeline — unverified: I could not run the repository's own build and validation pipeline, and neither could the Remediator. Every target that matters here -- make binaries, make lint, make validate-vendor, make validate-docs, make validate-generated-files -- runs through 'docker buildx bake', and there is no docker binary in this environment; golangci-lint is not installed either. I substituted 'go build -mod=vendor ./...' for the build on all eleven release platforms and reproduced validate-vendor's exact invariant under the repository's pinned Go version in a scratch copy, both of which are recorded above. There is no substitute available here for golangci-lint or for the docs and generated-file validation, so those were not run at all. Since the diff contains no Go source of the repository's own and no documentation, the docs and generated-file checks have little to bite on, but lint runs over the vendor tree in some configurations and I cannot say it passes. Closing this needs a CI run or a host with Docker.
• integration-suite — unverified: buildx's integration tests under ./tests need a Docker daemon and BuildKit images, and there is no docker binary here, so only the unit suite ran -- 13 packages with tests, all ok, which I reproduced. That leaves the paths these modules are actually used on unexercised end to end: grpc is the transport for BuildKit sessions and the buildx controller, x/crypto/ssh is on the SSH forwarding path, x/net/idna and http2 are on every registry request, and runc's libcontainer/user is reached through docker/docker's idtools. Compilation and the unit suite are real evidence but they are not that evidence. Closing this needs 'make test-integration' on a host with Docker.
• cve-2026-84304-behaviour — unverified: The denial of service itself was not reproduced before the change or shown absent after it, by the Remediator or by me. There is no Go vulnerability database entry for CVE-2026-84304, so govulncheck cannot speak to it in either direction and no scan here does. What I established instead is strong but indirect: the advisory's affected range is [0, 1.83.1) and the binary I built myself carries v1.83.1; the vendored google.golang.org/grpc tree is byte-identical to the authentic v1.83.1 release; the compaction rework is present in internal/transport/transport.go with compactBacklogLocked, uncompactedSuffixLen, uncompactedBytes and compactionThreshold, and internal/envconfig enables it by default with boolFromEnv(..., true) rather than behind an opt-in; and the two commits the advisory itself references are the ones the record names, with the first touching exactly the files the record lists. Closing this needs a Go database entry to scan against, or a load test driving fragmented HTTP/2 DATA frames through a BuildKit session.
• telemetry-behaviour — unverified: buildx's tracing and OTLP export behaviour was not exercised, so the one genuinely behavioural consequence of the forced OpenTelemetry advance is unmeasured. otelhttp v0.61.0 carries the HTTP semantic-convention migration relative to v0.48.0, which changes the attribute names emitted on outbound HTTP spans made through moby/buildkit's tracing transport and containerd's; and otelgrpc and otelhttptrace remain at v0.48.0 against otel v1.44.0, so the contrib set spans two release trains and relies on otel's 1.x compatibility promise rather than on lockstep. Compilation on all release platforms and a passing unit suite are the only evidence I have here. Closing this needs a build with tracing enabled against an OTLP collector.
• reachability-rederivation — unverified: I did not re-litigate the individual reachability judgements the dispositions made -- required-not-imported for the docker and runc findings, imported-not-called for x/crypto, symbol-reachable for x/text, and the argued override of govulncheck's symbol-reachable result on CVE-2025-52881. I did establish independently which vulnerable packages are in the build, which is the part that bears on this change: dnsmessage and the five docker/docker packages and all libcontainer runtime code are absent, while crypto/ssh, text/unicode/norm and grpc internal/transport are present. My before-and-after symbol-level scans corroborate the whole set moving as claimed. What I cannot say is that any individual reachability status in the dispositions is right, and under MCR's reachability policy it would not change the disposition anyway, since a present module at an affected version with a fixed version available is remediated regardless.

Advisory findings recorded but not blocking:

• rf-1: The change record's out_of_scope statement lists three residual govulncheck findings as the ones 'not in this work item', which reads as the complete set of what is deliberately left unfixed. My own symbol-level scan of the changed tree reports 41 unique advisories remaining, and the omissions include two further golang.org/x/crypto/ssh advisories that are fixed one minor above where this change lands.
• rf-2: Advancing grpc to v1.83.1 forces go.opentelemetry.io/otel and go.opentelemetry.io/otel/trace, both direct requirements of buildx, a minor forward, and go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp thirteen 0.x minors, leaving the contrib set split across two release trains. No disposition weighed any of it; the grpc remediation block weighed a cost of no other go.mod change at all.
• rf-3: Three factual statements in the disposition records are contradicted by this tree: the runc remediation block's cost figure, the grpc remediation block's cost figure, and the CVE-2026-46600 disposition's record of a build trial whose version combination minimal version selection cannot produce. The decisions those records reached still look right, but they were weighed against costs that were not the real costs, and at least one build trial appears not to have been run as described.

Not verified by the change author:

• cve-resolution for CVE-2026-84304 — The Go vulnerability database has no entry for CVE-2026-84304 / GHSA-vp52-pcj8-j9qc, so govulncheck cannot report it resolved and no scanner run here speaks to it. What was established instead: the shipped binary carries grpc v1.83.1, which is outside the advisory's [0, 1.83.1) affected range, and the compaction rework the two named upstream commits carry is present in the vendored internal/transport source and enabled by default. What is not established is behaviour: nothing exercised a stream of fragmented HTTP/2 DATA frames against the built plugin, so the denial of service was not reproduced before the change or shown absent after it. Closing this needs either a Go vulnerability database entry to scan against or a load test that drives fragmented DATA frames through a BuildKit session.
• integration suite — buildx's integration tests (./tests, 'make test-integration') need a Docker daemon and BuildKit images, and there is no docker binary in this environment. Only the unit suite ran ('SKIP_INTEGRATION_TESTS=1 go test -mod=vendor ./...', 13 packages with tests, all ok). Nothing here exercised a real build against a real BuildKit -- which is the path grpc, x/crypto/ssh and runc's idtools are actually used on. Closing this needs a run of 'make test-integration' on a host with Docker.
• repository build and validate pipeline — Every buildx Makefile target that matters here runs through 'docker buildx bake', and docker is absent: 'make binaries', 'make lint', 'make validate-vendor', 'make validate-docs' and 'make validate-generated-files' were all skipped. Two substitutes were used and are recorded in verification: 'go build -mod=vendor -o /dev/null ./...' for the build, and 'go mod tidy && go mod vendor' followed by an empty 'git status' for the vendor invariant, which is exactly what the vendor.Dockerfile validate stage compares. There is no substitute here for golangci-lint or for the docs and generated-file validation, so those were not run at all. Closing this needs a CI run, or a host with Docker.
• cross-platform build — Only linux/amd64 was compiled. buildx releases cross-compile ('make binaries-cross', the binaries-cross bake target) for darwin, windows and several linux architectures, and the vendored trees that moved include platform-specific files -- notably github.com/containerd/console, where v1.0.5 deletes console_zos.go, tc_solaris_cgo.go and tc_solaris_nocgo.go and adds console_other.go and pty_zos.go, and golang.org/x/sys, which is almost entirely per-platform. A break on a platform not built here would not have been seen. Closing this needs the cross build.
• go toolchain parity — The repository's vendoring and build images pin GO_VERSION=1.26.4 (hack/dockerfiles/vendor.Dockerfile); the toolchain that ran 'go mod tidy' and 'go mod vendor' here is go1.26.2. The regenerated go.sum and vendor tree are therefore not proven byte-identical to what the repository's own container would produce, and 'make validate-vendor' in CI is where that would show up. The risk is low -- both are 1.26 patch releases and the module graph is decided by the go directive in go.mod, which is go 1.25.0 -- but it is not zero and it was not checked.
• forced version over-shoot on golang.org/x/net and golang.org/x/text — The tree lands on golang.org/x/net v0.57.0 and golang.org/x/text v0.41.0, above the v0.56.0 and v0.39.0 the dispositions for CVE-2026-46600 and CVE-2026-56852 record, because golang.org/x/crypto v0.55.0 requires them. Both are past their fix, and the build and unit suite pass. What was not verified is that the extra minors carry no behavioural change for buildx: x/text/unicode/norm is on the hostname normalization path through x/net/idna and x/net/http2 is on every registry request, and nothing here exercised either beyond compilation and the unit tests. Closing this needs the integration suite, or a Triager decision that accepts v0.57.0 and v0.41.0 explicitly.
• forced advance of the OpenTelemetry modules — google.golang.org/grpc v1.83.1 forces go.opentelemetry.io/otel and go.opentelemetry.io/otel/trace -- both direct requirements of buildx -- from v1.43.0 to v1.44.0, and go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp from v0.48.0 to v0.61.0, thirteen minors. otelhttp's sibling contrib modules otelgrpc and otelhttptrace stay at v0.48.0, so the contrib set is now split across two release trains. This was verified only by compilation and the unit suite; buildx's tracing and OTLP export behaviour was not exercised at all, and none of it was weighed by any disposition. Closing this needs a build with tracing enabled against an OTLP collector, or a Triager decision on the otel advance.
• reachability analysis — The per-finding reachability claims in the dispositions -- required-not-imported for the docker and runc findings, imported-not-called for x/crypto, symbol-reachable for x/text, and the argued override of govulncheck's symbol-reachable result on CVE-2025-52881 -- were taken as given and not independently re-derived. What was run here is a whole-tree symbol-level govulncheck scan of base_commit and of the changed tree, which corroborates the before-and-after but does not re-litigate any individual reachability judgement.
• advisory sources — Every fixed version in this record was confirmed against the Go vulnerability database (vuln.go.dev) or, for CVE-2026-84304 which has no entry there, against osv.dev's copy of the GitHub advisory, and the two grpc commits were confirmed against the GitHub API. None of it was confirmed against a second independent source, and the CVE source portal's own recorded fixed versions were not re-read -- for CVE-2024-24557 the portal's v25.0.6+incompatible is known to disagree with the v24.0.9+incompatible used here, which the disposition had already corrected.

[corhere]

The bumps to docker/docker and opencontainers/runc are bogus: the respective CVEs only impact the application, not the module used as a library. But whatever; it'll shut up the scanners

[corhere]

Take a look at the failing integration tests. IIRC I hit the same failures when I tried bumping runc.