Bump bundled libSRT to v1.5.6 (fixes CVE-2026-55869, CVE-2026-55868)

[birme]

Fixes #89.

What

Bumps the bundled libSRT version from v1.5.5 to v1.5.6 in scripts/build-srt-sdk.js — a one-line change to SRT_CHECKOUT.

Why

Upstream Haivision/srt published two Critical (CVSS 9.1) security advisories on 2026-07-20, fixed in v1.5.6:

• CVE-2026-55869 — heap-based buffer overflow in KMREQ handling (GHSA-6xg9-784j-24rm)
• CVE-2026-55868 — encryption state machine downgrade (GHSA-4mc6-qmpp-g7gw)

Every @eyevinn/srt install currently builds and links the vulnerable v1.5.5.

Verification (macOS arm64, Node v22.13.1)

• npm run build-srt — clones and builds libSRT v1.5.6 cleanly (deps/build/lib/libsrt.1.5.6.dylib, version.h confirms 1.5.6); the existing configure-data.tcl.patch (macOS OpenSSL prefix) still applies without changes.
• npm run rebuild — node-gyp rebuild links the addon against the new library, gyp info ok, no errors (only pre-existing benign -mmacosx-version-min linker warnings).
• npm test — 22/22 jasmine specs pass.
• npm run check-tsc — no type errors.
• npm run test-jest — 22/24 pass; the same 2 failures occur identically on unmodified master (v1.5.5) — a pre-existing TypeError: The "this" argument must be an instance of Performance in integration-tests/async_srt_client_server_test.js:13 (const now = performance.now loses its this binding on modern Node; unrelated to this change, and not caught by CI since the nodejs.yml workflow only runs npm test, not npm run test-jest). Confirmed no new regressions by running both versions side by side.
• No changes needed to configure-data.tcl.patch or binding.gyp.

Scope note

Per the project's merge policy this is a native-build/libSRT-pin change (Tier B) — flagging for a human maintainer rather than requesting auto-merge, even with CI green.

---

Opened by the node-srt maintenance bot, implementing #89.

[birme]

CI update: this fails on Linux CI — 8 of 10 Node-version matrix jobs (18.x/20.x/22.x/24.x, and 26.x intermittently) show the identical pattern:

22 specs, 0 failures
Finished in ~1.3-1.5 seconds
Segmentation fault (core dumped)
##[error]Process completed with exit code 139.

All jasmine specs pass, then the process itself segfaults during shutdown — after the test summary prints. This does not reproduce locally on macOS arm64, and does not occur on unmodified master (v1.5.5) — confirmed clean on the last several master CI runs across the same Node matrix.

Not merging as-is. This looks like a real regression tied to the v1.5.6 upgrade (possibly interacting with src/node-srt.cc's per-instance srt_startup()/srt_cleanup() calls, which already carry a // Q: should we avoid to call this repeatedly comment flagging the lack of reference counting). Investigating root cause now; will report back before this is ready for maintainer review.

— node-srt maintenance bot

[birme]

Root cause found — this is an upstream libSRT bug, unrelated to either CVE fix.

Bisected the v1.5.5..v1.5.6 range by building each commit and running the suite in a clean Linux container (matching CI exactly). The segfault isolates to exactly one commit: Haivision/srt 1e4c908c ("[core] Removed unnecessary post-cleaning of closed socket in the cleanup", PR #3327) — the commit immediately before it is clean 4/4, that commit itself crashes 4/4.

A gdb backtrace at the crash shows why: at process exit, the main thread is inside CUDTUnited::~CUDTUnited() → CSndQueue::~CSndQueue() destroying send/receive-queue internals, while thread SRT:RcvQ:w1 is still running inside CRcvQueue::worker()" and segfaults on now-torn-down state. That commit changed the receive-queue worker's exit condition to depend on an invariant (m_bClosing`) that the global destructor never actually joins/waits on — a destroy-before-join race. It's timing-dependent (explains why one 26.x run passed and a rerun didn't) and much more reproducible on Linux than macOS.

I confirmed the two target CVE commits (KMREQ fix, encryption-downgrade fix) touch only crypto.cpp/core.cpp packet-parsing logic — no destructor/cleanup/thread-lifecycle code. They are not the cause. I also confirmed libSRT already reference-counts srt_startup/srt_cleanup internally, so node-srt's per-instance calls (the existing // Q: comment in src/node-srt.cc) aren't implicated either.

This isn't just a CI flake — it would plausibly crash real production processes on Linux too.

Not merging this as-is. Two paths forward, either needs a maintainer call:

1. File this upstream against Haivision/srt and wait for a v1.5.7 (or similar) that has the CVE fixes without the buggy cleanup refactor, then re-target this PR.
2. Rebuild from v1.5.5 with only the 5-6 security commits cherry-picked on top, explicitly excluding 1e4c908c. More engineering effort; needs verification the cherry-picks apply cleanly.

Leaving this PR open as a reference but marking not-mergeable pending that decision.

— node-srt maintenance bot

[birme]

Follow-up: tested the obvious alternative theory — that node-srt itself is misusing the library by never explicitly closing sockets (all of spec/*.js create sockets with zero .close() calls, which is exactly the 'misuse' PR #3327's own description warns about).

Directly disproven by experiment: modified all four spec files to explicitly .close() every socket (sync and async) before each test ends, everything else unchanged. Still segfaults 4/4, identical signature (22 specs, 0 failures → SIGSEGV in CRcvQueue::worker() racing ~CUDTUnited()). So this isn't caller-side socket hygiene — libSRT's own stopGarbageCollector()/global-destructor sequencing has the race regardless of whether the JS caller closed its sockets. It's also not fixable from node-srt's binding layer: the crash is in the automatic static destruction of libSRT's global CUDTUnited singleton at real process exit (__run_exit_handlers), a code path outside any NodeSRT/AsyncSRT object lifecycle node-srt controls.

Conclusion unchanged, now on firmer evidence: hold this bump. Options remain (a) report upstream to Haivision/srt with this evidence and wait, or (b) cherry-pick just the CVE-fix commits onto v1.5.5, explicitly excluding 1e4c908c.

— node-srt maintenance bot

[birme]

Thank you for opening this PR so quickly after the CVE advisory, and for the thorough local verification and the detailed gdb root-cause analysis in Issue #89 — that work is genuinely appreciated and will be essential for whoever takes the next step.

The node-srt maintenance bot cannot recommend merging in the current state. CI is failing on Linux (Node 18.x through 22.x) with a SIGSEGV at process exit (exit code 139): the jasmine suite passes 22/22, but Node crashes immediately afterward inside libSRT's global destructor. The CI logs confirm this directly — all 22 specs succeed, then the process exits with Segmentation fault (core dumped) on Node 18 and Node 22. Based on the bisection reported in #89 (Haivision/srt PR #3327, commit 1e4c908c), this is a confirmed upstream regression in libSRT v1.5.6 — a shutdown-race between libSRT's global-destructor and an internal GC worker thread. The crash is not a test flake and is not addressable from the node-srt side; explicitly closing all sockets before exit does not prevent it.

The build pipeline itself is clean: npm install, cmake, node-gyp rebuild, and linking all succeed on every Node version tested. No changes to binding.gyp or configure-data.tcl.patch are needed for v1.5.6. The blocker is entirely in libSRT's runtime behavior at process exit.

Node 26.x did not exhibit the crash in the one successful CI run, but given that this is a timing-sensitive shutdown race, that one data point is not a safe signal for a production merge.

The merge policy requires all required CI checks to be green, so this PR is blocked until the regression is resolved. Three paths forward:

1. Wait for upstream — if Haivision publishes a v1.5.7 that reverts 1e4c908c while retaining the CVE fixes, bump SRT_CHECKOUT to that tag.
2. Cherry-pick the CVE fixes onto v1.5.5 — modify scripts/build-srt-sdk.js to check out v1.5.5 and apply a targeted patch containing only the security commits, bypassing the regression commit. This is more complex but provides the security fix without the wait.
3. Document NODE_SRT_CHECKOUT as a temporary workaround for users who can accept the risk and need the security fix now.

This is a Tier B (native-build/libSRT-pin) decision — flagged ready-for-maintainer so a human maintainer can choose the path. Please keep this PR open; it is the correct vehicle for the fix once the upstream situation is resolved.

— node-srt maintenance bot