fix: correct gvisor replace directive to match module path

[denisra]

Summary

Fixes the gvisor replace directive in go.mod to target the correct module path.

Supersedes #26750 (closed).

Problem

PR #23055 added a replace directive to use the coder/gvisor fork (which fixes an integer overflow causing panic: length < 0 crashes). However, the directive targeted the wrong module path:

replace gvisor.dev => github.com/coder/gvisor v0.0.0-20260313164934-7a658db7b714

The actual module path declared in gvisor's go.mod is gvisor.dev/gvisor, not gvisor.dev. Go module replace directives require an exact module path match, so the previous directive was a no-op and the patched fork was never used.

Fix

-replace gvisor.dev => github.com/coder/gvisor v0.0.0-20260313164934-7a658db7b714
+replace gvisor.dev/gvisor => github.com/coder/gvisor v0.0.0-20260313164934-7a658db7b714

Validation

Verified locally with go list -m:

Before (no-op replace):

$ go list -m gvisor.dev/gvisor
gvisor.dev/gvisor v0.0.0-20240509041132-65b30f7869dc

After (correct replace):

$ go list -m gvisor.dev/gvisor
gvisor.dev/gvisor v0.0.0-20240509041132-65b30f7869dc => github.com/coder/gvisor v0.0.0-20260313164934-7a658db7b714

The => confirms the fork is now applied.

Note: go.sum will need a go mod tidy run to update checksums. CI should flag this.

Fixes #20885

---

Investigation context

• The coder/gvisor fork (commit 7a658db7b714) declares module gvisor.dev/gvisor in its go.mod
• Customer runtime stack traces show gvisor.dev/gvisor@v0.0.0-20240509041132-65b30f7869dc (unpatched upstream), confirming the fork was not applied
• The crash is panic: length < 0 in gvisor.dev/gvisor/pkg/tcpip/transport/tcp.(*sender).splitSeg
• Related Linear ticket: ENT-118

---

Generated by Coder Agents on behalf of @denisra

[denisra]

Validation

Fully validated this fix by reproducing the bug on the unpatched gVisor version and confirming it's resolved with the fork.

Reproducer tool

Added scripts/gvisor-overflow-repro/, a standalone tool that reproduces the integer overflow from #20885. It creates a real gVisor userspace TCP stack, establishes a connection, then uses reflect+unsafe to force SndCwnd to the overflow threshold (simulating weeks of CUBIC congestion window growth with no packet loss). A subsequent write exercises the sendData path where (SndCwnd - Outstanding) * MaxPayloadSize overflows.

Run with:

go run ./scripts/gvisor-overflow-repro/
go test -v ./scripts/gvisor-overflow-repro/

Scenario 1: Unpatched gVisor (v2.33.5 customer version)

Built the reproducer against the raw upstream gvisor.dev/gvisor@v0.0.0-20240509041132-65b30f7869dc (the version v2.33.5 actually uses, since the old replace gvisor.dev => directive was a no-op).

=== gVisor TCP SndCwnd Overflow Reproducer ===
Issue: https://github.com/coder/coder/issues/20885

[1] Connection established, sending initial data...
[2] Extracting TCP endpoint internals via reflect+unsafe...
    MaxPayloadSize (MSS): 65483
    SndCwnd before:       11
    Overflow threshold:   140851397108482 (MaxInt/MSS)
    SndCwnd set to:       140851397108483 (threshold + 1)

[!] SndCwnd accepted uncapped value 140851397108483. The vulnerability may be present.

[3] Writing data to trigger TCP send path (cwndLimit calculation)...
    On vulnerable gVisor: this triggers panic('length < 0')
    On fixed gVisor:      SetSndCwnd caps the value, preventing overflow

[FAIL] PANIC caught: length < 0
       The gVisor TCP integer overflow bug is PRESENT.
       The coder/gvisor fork fix is NOT active.

=== Reproducer complete ===

Result: panic: length < 0 — matches the customer stack traces in #20885.

Scenario 2: Patched gVisor (this PR)

Built against the coder/gvisor fork (github.com/coder/gvisor@v0.0.0-20260313164934-7a658db7b714) with the corrected replace directive.

=== gVisor TCP SndCwnd Overflow Reproducer ===
Issue: https://github.com/coder/coder/issues/20885

[1] Connection established, sending initial data...
[2] Extracting TCP endpoint internals via reflect+unsafe...
    MaxPayloadSize (MSS): 65483
    SndCwnd before:       11
    Overflow threshold:   140851397108482 (MaxInt/MSS)
    SndCwnd set to:       140851397108483 (threshold + 1)

[!] SndCwnd accepted uncapped value 140851397108483. The vulnerability may be present.

[3] Writing data to trigger TCP send path (cwndLimit calculation)...
    On vulnerable gVisor: this triggers panic('length < 0')
    On fixed gVisor:      SetSndCwnd caps the value, preventing overflow

[OK] Write succeeded without panic.
     The overflow did NOT cause a panic. Fix is working.

=== Reproducer complete ===

Result: no panic. The fork's cwndLimit < 0 guard in sendData catches the overflow.

Note: the SndCwnd accepted uncapped value message appears because the reproducer writes directly to the field via unsafe (bypassing SetSndCwnd) to test the second defense layer. In normal operation, SetSndCwnd would cap the value at MaxCwnd (1<<30) before it ever reaches the overflow threshold.

Unit tests

Two tests validate both defense layers of the fork:

=== RUN   TestCwndLimitOverflowGuard
    main_test.go:122: product (SndCwnd * MSS) = -9223372036854759327 (WOULD overflow)
    main_test.go:132: Write completed without panic. cwndLimit overflow guard is working.
--- PASS: TestCwndLimitOverflowGuard (0.05s)
=== RUN   TestSetSndCwndCapsOverflow
    main_test.go:175: SetSndCwnd(1073741825) correctly capped to MaxCwnd=1073741824
    main_test.go:189: SetSndCwnd(-1) correctly capped to MaxCwnd=1073741824
--- PASS: TestSetSndCwndCapsOverflow (0.05s)
PASS

Additional validation

• go list -m gvisor.dev/gvisor confirms the fork is active: => github.com/coder/gvisor v0.0.0-20260313164934-7a658db7b714
• go version -m on the compiled binary confirms the fork is linked
• Dev server built and deployed successfully from this branch

---

Generated by Coder Agents on behalf of @denisra

[linear-code]

ENT-118

[sreya]

LGMT but I'd remove the scripts/ additions, I think a regression test is unnecessary here