Skip to content

Bump gvisor.dev/gvisor to 3b87f090dbda and fix ICMP echo to gateway - #771

Open
evidolob wants to merge 2 commits into
containers:mainfrom
evidolob:update-gvisor
Open

evidolob wants to merge 2 commits into
containers:mainfrom
evidolob:update-gvisor

Conversation

@evidolob

@evidolob evidolob commented Nov 5, 2026

Copy link
Copy Markdown
Collaborator

Bumps gvisor.dev/gvisor from 9680d69bf798 (2026-04-13) to 3b87f090dbda1fefedbfbe94183324e9c8e13494 (2026-10-08) on the upstream go branch, and adapts the ICMP forwarder to a gvisor behavior change.

Why this commit

3b87f090dbda is the newest go branch snapshot whose go.mod still requires Go 1.26. Later snapshots require Go 1.27.3 and also include the pkg/state graph-engine rewrite. go mod tidy raises our go directive from 1.26.0 to 1.26.3; the CI matrix (1.26.x, 1.27.x) covers that.

Notable upstream changes

  • tcp: strict RFC 5961 RST validation, DF bit on the handshake, FIN_WAIT1 when a FIN is queued, CUBIC/RACK fixes, a segment leak fix when TIME-WAIT reuse fails
  • udp: checksum 0 handling, a PacketBuffer leak fix in the forwarder, receive buffer accounting
  • ipv4/ipv6: no echo replies to broadcast/multicast, reassembly length limit, stricter parsing

ICMP fix (second commit)

gvisor 8b0e16201 ("netstack: let ICMP echo handlers consume requests") treats a default transport handler returning true as having consumed the echo request, and then skips the built-in reply. Our forwarder returned true for pings to the stack's own addresses (e.g. the gateway) to mean "leave it to the stack", so with the bump those pings went unanswered. The should leave pings to the gateway's own address to the stack test caught this. The handler now returns false for those packets. This also works with the previous gvisor, which ignores the return value on this path.

The fix is a separate commit, so the forwarder test fails at the first commit on its own.

Testing

  • make cross
  • go vet ./...
  • go test ./pkg/...: all pass, including the forwarder ICMP tests (fails without the second commit)

🤖 Generated with Claude Code

evidolob and others added 2 commits November 5, 2026 14:30
Update gvisor.dev/gvisor from 9680d69bf798 (2026-04-13) to
3b87f090dbda1fefedbfbe94183324e9c8e13494 (2026-10-08) on the go branch.
This is the newest go branch snapshot whose go.mod still requires Go
1.26; later snapshots require Go 1.27.3.

Notable changes in the vendored packages:
- tcp: strict RFC 5961 RST sequence validation, DF bit on the
  handshake, FIN_WAIT1 when a FIN is queued, CUBIC/RACK fixes, and a
  segment leak fix when TIME-WAIT reuse fails
- udp: checksum 0 handling, PacketBuffer leak fix in the forwarder,
  packet overhead accounted in receive buffer limits
- ipv4/ipv6: no echo replies to broadcast/multicast, reassembly length
  limit, stricter parsing
- ICMP echo requests consumed by a default transport handler no longer
  get the built-in reply (8b0e16201)

go mod tidy raises the go directive to 1.26.3 and bumps the indirect
golang.org/x/exp and golang.org/x/time dependencies.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Yevhen Vydolob <yvydolob@redhat.com>
The ICMP forwarder's default handler returned true for echo requests
sent to an address the stack owns, intending to leave them to gvisor's
built-in echo reply. Since gvisor 8b0e16201 ("netstack: let ICMP echo
handlers consume requests"), a default handler returning true means it
consumed the packet, and gvisor no longer sends its own reply. Pings
from the VM to the gateway's address therefore went unanswered.

Return false for these packets so gvisor still replies. Older gvisor
versions ignore the return value on this path, so the change is safe
with them too.

Fixes the "should leave pings to the gateway's own address to the
stack" forwarder test.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Yevhen Vydolob <yvydolob@redhat.com>
@openshift-ci

openshift-ci Bot commented Nov 5, 2026

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: evidolob

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci Bot added the approved label Nov 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant