Deflake test_linux_network_stacksmash_64

[DanielBotnik]

Summary

test_linux_network_stacksmash_64 was wrapped in @flaky(max_runs=3, min_passes=1) to paper over two races in the phase-2 "run the exploit" step. This replaces the retry wrapper with deterministic synchronization.

The exploit itself is not the flaky part: network_overflow is a non-PIE binary whose talk() memcpys the received bytes to a fixed .bss address (0x4040c0) and the exploit overwrites the saved return address to jump there, so it works independently of ASLR. The flakiness was entirely in how the test launched and connected to the target:

1. Random ports (random.randint(...)) could already be in use. The target server does not set SO_REUSEADDR, so its bind() then fails and the test errors out through no fault of the exploit.
2. time.sleep(.5) was used to wait for the server before launching the exploit, whose generated script connects once with no retry. On a loaded CI runner the server can take longer than 0.5s to reach listen(), so the connection is refused.

(Phase 1 doesn't suffer this — archr connects with retry=30.)

Changes

• _get_free_tcp_port() — bind to port 0 to get a port the OS reports as free, instead of a random one that may be taken.
• _wait_until_listening() — poll the socket's LISTEN state (via psutil, already a transitive dependency through angr/pwntools) instead of sleeping a fixed interval. We check state rather than connecting because the target accept()s exactly one connection, so a probe connection would be consumed instead of the exploit's.
• Remove the @flaky decorator and the now-unused flaky dependency.

Testing

Ran the test with flaky retries disabled (-p no:flaky):

• 30/30 passes back-to-back.
• 5/5 passes under full-CPU stress (the slow-startup condition that triggered the original flake).

Also verified directly that the old sleep(0.5) + no-retry connect fails with ConnectionRefusedError against a server that takes >0.5s to listen(), while _wait_until_listening handles it.

🤖 Generated with Claude Code

[ltfish]

Ask Claude Code to try harder ;)

[DanielBotnik]

Took another pass at this and found the real root cause behind the flakiness:

1. The target services a connection with a single recv(), but the generated call_shellcode exploit sent the shellcode payload and the follow-up commands (echo hello\n, exit\n) back to back — under load they coalesce into that one read, so the commands get consumed before the shell is up and it blocks forever on empty stdin (the 30s timeout you saw).
2. Fix: pace the exploit — wait SHELL_SPAWN_DELAY after the payload before sending commands, so the payload is alone in the first read.
3. Also made the test deterministic: guaranteed-free ports (no EADDRINUSE) and wait-until-listening via psutil instead of a fixed sleep(.5).
4. Dropped the @flaky wrapper and dependency since the races are now fixed at the source.
5. Reproduced the hang deterministically and verified the paced exploit works; the call_shellcode change also makes real network shellcode exploits more reliable, not just this test.