Backport #4729: Upgrade libsrt to 1.5.6 for security enhancement. v6.0.192 - #4732
Merged
Merged
Conversation
Backport of ossrs#4729 to SRS 6.0. Replace the vendored srt-1-fit tree with upstream SRT v1.5.6 to pick up two remotely reachable security fixes: - CVE-2026-55869 (upstream PR ossrs#3317): processSrtMsg_KMREQ copied bytelen/4 words into a 104-byte stack buffer with no capacity check. - CVE-2026-55868 (upstream PR #3319): processSrtMsg_KMRSP did the same with no validation of len at all. Both were reachable through the post-connect UMSG_EXT control packet path, which has no passphrase gate, so a peer that completes a handshake could overflow the stack buffer by about 1352 bytes. SRT is off by default at runtime, so only deployments that explicitly enable srt_server were exposed. 1.5.6 also carries three hardening fixes (upstream PR ossrs#3324, #3320, ossrs#3322). The 6.0 fit tree was byte-identical to the one on develop, a pure subset of upstream 1.5.3 with no local edits, so 1.5.6 is vendored the same way: apps, tests, docs, examples, CI files, and the new submodules directory are pruned, everything else is pristine upstream. Retarget patches/srt/api.cpp-01.patch from line 1116 to 1312. The old number was already stale for 1.5.3, where the line sat at 1133 and patch located it by content. Add srs_srt_cleanup() and call it from SrsServer::stop() and from the utest main. SRS starts libsrt lazily and never stopped it, so its worker threads outlived the libsrt global objects destroyed at exit. Since 1.5.6, ~LogDispatcher resets its config pointer to NULL while Proxy::Proxy still dereferences it after a non-atomic CheckEnabled(), so a worker thread logging during teardown can crash. On develop this reproduced as a deterministic SEGV in the utest. It does not reproduce in 6.0, whose utest leaves no worker logging at exit, but the same race is present: before this change an SRT worker still logged after the final "srs terminated" line on graceful shutdown, and now it does not. Both call sites are guarded by SRS_SRT. Verified: libsrt builds reporting SRT_VERSION_STRING "1.5.6", the api.cpp patch applies with no offset, make completes for both --srt=on and --srt=off, utest passes 588/588 across three runs, srs reports 6.0.192, and srt_server binds UDP 10080 and shuts down gracefully with no worker log after teardown. --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #4729 to SRS 6.0, upgrading the vendored SRT library from 1.5.3 to 1.5.6.
Fixes #4727 for the 6.0 branch, which is the release the issue originally asked about.
Both CVEs fixed in upstream 1.5.6 were confirmed reachable in SRS, not merely present by version number:
processSrtMsg_KMREQcopiedbytelen/4words into a 104-byte stack buffer with no capacity check. The existingbytelen <= HCRYPT_MSG_KM_OFS_SALTtest is a lower bound and runs after the copy.processSrtMsg_KMRSPdid the same with no validation oflenat all.The enforced-encryption gate in
interpretSrtHandshakecovers the handshake path, but not the post-connectUMSG_EXTcontrol packet path, which has no passphrase gate and reaches both handlers on any established connection. At the default MSS of 1500 that is roughly 1352 bytes of stack overflow from any peer that completes a handshake.SRT is off by default at runtime (
get_srt_enabled()returns false and stockconf/srs.confhas nosrt_serverblock), so only deployments that explicitly enablesrt_serverwere exposed.1.5.6 also carries three hardening changes (upstream PRs #3324, #3320, #3322), which matter less in SRS — full reachability analysis in #4727 (comment)