René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Silent process crash: /GS stack-buffer-overrun in libuv Windows TCP-connect path under high outbound HTTP-connection volume (24.15.0; appears fixed in 24.16.0)","articleBody":"### Version\n\nReproduces on **v24.15.0** (libuv 1.51.0). Appears fixed on **v24.16.0** (libuv 1.52.1). Also clean on **v25.9.0** (libuv 1.51.0).\n\n### Platform\n\n```text\nWindows x64 (GitHub-hosted `windows-latest`). Not observed on Linux.\n```\n\n### Subsystem\n\nlibuv (Windows TCP connect: `uv__tcp_connect` / `uv__tcp_try_connect`), reached via `net`/`http` client APIs and `TCPWrap::Connect`.\n\n### What steps will reproduce the bug?\n\nA Node process that makes a high volume of short-lived **outbound** HTTP connections on Windows intermittently dies with no catchable error. Pure-Node repro — save as `repro.js` in an empty directory and run a few times on Windows + Node 24.15.0:\n\n```js\n// repro.js — no dependencies. Storms short-lived loopback HTTP connections\n// (keep-alive off) against an in-process server.\nconst http = require('http');\nconst HOST = process.env.REPRO_HOST || '127.0.0.1'; // 127.0.0.1 reproduced 100% of trials\nconst DURATION_MS = Number(process.env.DURATION_MS || 60000);\nconst CONCURRENCY = Number(process.env.CONCURRENCY || 96);\n\nconst server = http.createServer((req, res) =\u003e { res.end('ok'); });\nserver.listen(0, HOST, () =\u003e {\n  const { port } = server.address();\n  const agent = new http.Agent({ keepAlive: false, maxSockets: CONCURRENCY });\n  const end = Date.now() + DURATION_MS;\n  let outstanding = 0, made = 0, done = false;\n  const finish = () =\u003e { if (!done) { done = true; console.log(`done: ${made} reqs, no crash`); server.close(() =\u003e process.exit(0)); } };\n  const pump = () =\u003e {\n    while (outstanding \u003c CONCURRENCY \u0026\u0026 Date.now() \u003c end) {\n      made++; outstanding++;\n      const req = http.get({ host: HOST, port, agent }, (res) =\u003e { res.resume(); res.on('end', () =\u003e outstanding--); });\n      req.on('error', () =\u003e outstanding--);\n    }\n    if (Date.now() \u003c end) setImmediate(pump);\n    else if (outstanding === 0) finish();\n  };\n  const wd = setInterval(() =\u003e { if (Date.now() \u003e= end \u0026\u0026 (outstanding === 0 || Date.now() \u003e= end + 10000)) { clearInterval(wd); finish(); } }, 250);\n  wd.unref();\n  pump();\n});\n```\n\n```\nnode repro.js\n```\n\nTo capture the otherwise-invisible crash, enable a full dump on silent exit (elevated PowerShell) before running:\n\n```powershell\n$dumps = \"C:\\node-dumps\"; New-Item -ItemType Directory -Force -Path $dumps | Out-Null\n$ifeo = \"HKLM:\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\node.exe\"\n$spe  = \"HKLM:\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\node.exe\"\nNew-Item -Path $ifeo -Force | Out-Null\nNew-ItemProperty -Path $ifeo -Name GlobalFlag     -PropertyType String -Value \"0x200\" -Force | Out-Null  # FLG_MONITOR_SILENT_PROCESS_EXIT\nNew-Item -Path $spe -Force | Out-Null\nNew-ItemProperty -Path $spe -Name ReportingMode   -PropertyType DWord  -Value 2 -Force | Out-Null         # LOCAL_DUMP\nNew-ItemProperty -Path $spe -Name LocalDumpFolder -PropertyType String -Value $dumps -Force | Out-Null\nNew-ItemProperty -Path $spe -Name DumpType        -PropertyType DWord  -Value 2 -Force | Out-Null         # full memory\n```\n\n### How often does it reproduce? Is there a required condition?\n\nRequired condition: Windows + Node 24.0–24.15 (libuv 1.50/1.51) + a high rate of short-lived **outbound** HTTP connections. On 24.15.0 it crashed in **4/4** CI jobs with `REPRO_HOST=127.0.0.1` and **2/4** with `localhost` (each job = 4 × 60 s trials). Address-family independent (both `sockaddr_in` and `sockaddr_in6`). A raw `net.connect()` + immediate `destroy()` storm did **not** trigger it — the HTTP request/response round-trip (or `http.Agent` connect setup) seems required, not the bare TCP connect.\n\n### What is the expected behavior? Why is that the expected behavior?\n\nThe connection storm runs to completion (prints `done: …`) and the process exits 0, as it does on Linux and on Node 24.16.0 / 25.x.\n\n### What do you see instead?\n\nThe process dies mid-run with no `'exit'`/`uncaughtException`/`unhandledRejection`, no `--report-on-fatalerror`/`--report-on-signal` output, and no standard SEH/WER crash record — a \"silent\" death. A full-memory dump shows the main thread executing a `/GS` stack-cookie failure (a stack buffer overrun) in the connect path:\n\n```\nnode::TCPWrap::Connect\u003csockaddr_in6\u003e           (also \u003csockaddr_in\u003e)\n  → uv_tcp_connect\n    → uv__tcp_connect / uv__tcp_try_connect     (identical-COMDAT-folded)\n      → __security_check_cookie → __report_gsfailure → __fastfail(2)\n```\n\n`RIP` is inside `__report_gsfailure`; bytes at `RIP` are `cd 29` (`int 29h` = `__fastfail`); `ecx = 2` (`FAST_FAIL_STACK_COOKIE_CHECK_FAILURE`). The corrupted frame is `uv__tcp_connect`'s (~0x218 bytes); in every captured sample the `/GS` cookie was overwritten but the saved return address (the slot above it) was intact, so `/GS` turned the corruption into a controlled crash. Symbolized against the official `node.pdb` for 24.15.0 (debug-id `3c541b69-34a1-cd3f-…`).\n\n### Additional information\n\n**Version bisect** (Windows `windows-latest`; each cell = jobs × 4 × 60 s trials):\n\n| Node | bundled libuv | `localhost` (→ ::1) | `127.0.0.1` |\n|---|---|---|---|\n| 24.15.0 | 1.51.0 | crashes (2/4) | **crashes (4/4)** |\n| 24.16.0 | 1.52.1 | clean (0/4) | clean (0/4) |\n| 25.9.0 | 1.51.0 | clean (0/4) | clean (0/4) |\n\nIt **appears already fixed in 24.16.0**, so the main asks are:\n1. Can you **confirm the fix is intentional and complete** on the 24.x LTS line? Note 25.9.0 is clean *despite carrying the same nominal libuv (1.51.0)* as the broken 24.15.0, so the fix doesn't map to the upstream libuv tag alone — likely a back-ported libuv patch and/or a Node/V8/build difference present in 24.16.0 and 25.x but not 24.15.0. Identifying the exact commit would confirm coverage.\n2. Since it's a **memory-safety defect** (out-of-bounds stack write, CWE-121) that causes an unrecoverable crash, does it warrant a **security advisory** so users still on 24.0–24.15 are notified to upgrade? I've kept a private/HackerOne-formatted writeup ready if you'd prefer to handle it through the security process — happy to route it there instead.\n\n**Relevant source:**\n- Node: `src/tcp_wrap.cc` — `TCPWrap::Connect` (https://github.com/nodejs/node/blob/main/src/tcp_wrap.cc)\n- libuv (bundled at `deps/uv`): `src/win/tcp.c` — `uv_tcp_connect` / `uv__tcp_connect` (https://github.com/libuv/libuv/blob/v1.x/src/win/tcp.c)\n\nI can provide the symbolized full-memory minidump(s), the complete faulting-thread stack + registers, the full bisect matrix, and the non-triggering raw-TCP variant for diffing.","author":{"url":"https://github.com/JohnMcLear","@type":"Person","name":"JohnMcLear"},"datePublished":"2026-05-28T14:49:29.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/63620/node/issues/63620"}