TCP listening socket stops accepting after checkpoint/restore under connection load

[yaseenisolated]

Description

A TCP listening socket inside a sandbox doesn't accept new connections after runsc restore - but only when the checkpoint was taken
while connections were actively being processed (the netstack TCP dispatcher's
per-processor run-queues were non-empty). The restored process is otherwise
healthy; only inbound connectivity to the listener is dead.

This is reproducible on all releases but tested on runsc release-20260608.0

Steps to reproduce

The steps below are encapsulated in check.sh and repro.go.

1. Run a binary under runsc that opens a listening socket and then repeatedly dials and sends packets to that socket.
2. Run runsc checkpoint on the sandbox
3. Run runsc restore.
4. Note that you cannot connect to the listening socket.

This seems obscure but we ran into it in production and came up with a fix.

If you don't hammer the listening socket during checkpoint then we can access the listening socket just fine on restore.
check.sh

repro.go.md

runsc version

runsc version release-20260608.0
spec: 1.2.1

docker version (if using docker)

na

uname

No response

kubectl (if using Kubernetes)

Linux 6.8.0-1057-aws #60~22.04.1-Ubuntu SMP x86_64 (Ubuntu 22.04, AWS c6i.xlarge)

repo state (if built from source)

used release-20260608.0

runsc debug logs (if available)

No relevant debug logs.

[yaseenisolated]

My theory that was validated with a fix:

When hammering the listener socket during checkpoint the epQueue in pkg/tcpip/transport/tcp/dispatcher.go is not empty and has some of the segments in it.

But serializing this struct serializes incorrectly for a few reasons. One the linked list is self referential and isn't marked as state:"wait". When we do mark it as "wait" the beforeSave on the Endpoint struct corrupts the list because it mutates the list as we go along corrupting the linked list.

But don't we drain this struct during checkpoint? Shouldn't the queue be empty? Yes but while it's draining it is still receiving packets from the local binary because it is not yet frozen.

So instead of serializing the queue properly I rather rebuild the queue at restore time since each endpoint has enough information about whether it should be queued for processing or not.