[release-1.3] Bump golang.org/x/net to v0.57.0 (requires Go 1.25)#5368
[release-1.3] Bump golang.org/x/net to v0.57.0 (requires Go 1.25)#5368smerkviladze wants to merge 1 commit into
Conversation
Also bump golang.org/x/sys to v0.47.0. Both modules now require Go 1.25, so raise the go directive in go.mod from 1.23.0 to 1.25.0 and drop Go 1.23 from the CI test matrix. Starting with Go 1.25, the runtime opens the cgroup CPU limit files (cpu.cfs_quota_us and cpu.cfs_period_us on cgroup v1, cpu.max on cgroup v2) and keeps them open to periodically re-evaluate GOMAXPROCS (https://go.dev/cl/670497\). As a result, a container's init process now legitimately holds these file descriptors, which the fd leak integration test used to flag as a leak. Add them to the test's whitelist of allowed fd targets. Signed-off-by: Sopho Merkviladze <smerkviladze@mirantis.com>
|
Why is this needed? I didn't follow |
The bump satisfies vulnerability scanners that flag the module version (CVE-2026-39821). |
|
@smerkviladze Oh, that wasn't mentioned at all. Also, the commit seems to do quite more stuff that updaging the dependency. If you copied stuff from main, a proper cherry-pick is what is expected. But there is no earlier release that fixes the CVE that maybe doesn't require a go update? |
Unfortunately, no. The CVE is fixed in x/net v0.55.0, and every release containing the fix requires Go 1.25. The last x/net version that still builds with Go 1.23 is v0.43.0, which predates the fix; so bumping past the CVE unavoidably raises the minimum Go version. Please let me know if the Go bump is acceptable for release-1.3, and I will split the PR into separate commits and cherry-pick the relevant ones from upstream. |
|
Hmm, but I don't think we use the vuln functions directly/indirectly, right? govulncheck probably doesn't report it, right? It's just scanners that just check the version the problem? Which one in particular are you seeing the issue with? |
Correct on both counts. I ran govulncheck on release-1.3 to confirm: "Your code is affected by 0 vulnerabilities. This scan also found … 1 vulnerability in modules you require, but your code doesn't appear to call these vulnerabilities." So yes, it's version-matching scanners flagging the module version rather than an actual exposure. In our case it's Sysdig, which scans the vendored module versions and flags golang.org/x/net < v0.55.0 regardless of which packages are used. |
|
We did changed it once: #4277 (comment) Oh, but this is v1.3. It will receive high severity fixes now, see the policy: https://github.com/opencontainers/runc/blob/main/RELEASES.md#support-policy. And it will be unsupported in a few months. Can't you update to runc 1.5? Updating the dep there is also simpler :) |
2 participants
Bumps
golang.org/x/netto v0.57.0, andgolang.org/x/systo v0.47.0 (required by the new x/net);The version bump satisfies vulnerability scanners that flag the affected module version: CVE-2026-39821
Both modules require Go 1.25, so this raises the minimum Go version for building runc on this branch from 1.23 to 1.25:
go.mod: go directive 1.23.0 → 1.25.01.23.xdropped from the test matrix (1.25.x and 1.26.x remain)The Go 1.25+ runtime holds cgroup CPU limit fds open for container-aware GOMAXPROCS (https://go.dev/cl/670497), which trips the fd-leak integration test. Whitelisted the v1 files; plus the cgroup v2
cpu.maxequivalent, which shows up when the test runs in nested-container environments.