Backport #4729: Upgrade libsrt to 1.5.6 for security enhancement. v7.0.160 - #4730
Merged
Merged
Conversation
…ancement. Backport the SRT 1.5.6 upgrade from develop (9ff7e24) to SRS 7.0, which fixes two remotely reachable stack overflows: - 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. The enforced-encryption gate in interpretSrtHandshake blocks the handshake path when no passphrase is configured, but the post-connect UMSG_EXT control packet path (CUDT::processSrtMsg) has no such gate and needs no passphrase, 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) for out-of-bounds reads in LOSSREPORT and DROPREQ parsing and a drop-range guard in CRcvBuffer::dropMessage. Also backport srs_srt_cleanup(). SRS started 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, so a worker thread logging during teardown dereferences it and crashes. Calling srt_cleanup() from SrsServer::stop() and from the utest main stops libsrt and joins those threads first. The utest needs its own call because it has a separate main that never goes through SrsServer::stop(). This commit carries the code change only. The version bump and the changelog entry are not included. Verified on this branch: libsrt builds reporting SRT_VERSION_STRING "1.5.6", the api.cpp patch applies with no offset, the srs binary links against 1.5.6, utest passes 2195/2195 over three runs with no SEGV or AddressSanitizer error under ASAN, and all eight bundled integration scripts pass, including the SRT publish test verifying RTMP, HTTP-FLV, and HLS playback. The vendored tree is byte-identical to develop after 9ff7e24. --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
winlinvip
changed the title
winlinvip
changed the title
winlinvip
added a commit
that referenced
this pull request
Aug 20, 2026
…0.160 (#4730) Backport of #4729 to SRS 7.0: upgrade the vendored SRT library from 1.5.3 to 1.5.6 to fix two remotely reachable security vulnerabilities. Backports #4729. Relates to #4727. SRS 7.0 vendors SRT 1.5.3 and is affected by both CVEs exactly as `develop` was: - **CVE-2026-55869** (upstream PR #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. The enforced-encryption gate in `interpretSrtHandshake` blocks the handshake path when no passphrase is configured, but it does **not** cover the post-connect `UMSG_EXT` control packet path (`CUDT::processSrtMsg`), which has no passphrase gate. At the default MSS of 1500 that is roughly **1352 bytes of stack overflow** from any peer that completes a handshake, before SRS-level streamid or callback auth ever runs. 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 PRs #3324, #3320, drop-range guard in `CRcvBuffer::dropMessage`. These matter less in SRS — the two OOB reads land inside the allocated packet slot, and the `dropMessage` guard is unreachable under SRS defaults. Full reachability analysis: #4727 (comment) --- 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
1 participant
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 7.0: upgrade the vendored SRT library from 1.5.3 to 1.5.6 to fix two remotely reachable security vulnerabilities.
Backports #4729. Relates to #4727.
SRS 7.0 vendors SRT 1.5.3 and is affected by both CVEs exactly as
developwas:processSrtMsg_KMREQcopiedbytelen/4words into a 104-byte stack buffer with no capacity check.processSrtMsg_KMRSPdid the same with no validation oflenat all.The enforced-encryption gate in
interpretSrtHandshakeblocks the handshake path when no passphrase is configured, but it does not cover the post-connectUMSG_EXTcontrol packet path (CUDT::processSrtMsg), which has no passphrase gate. At the default MSS of 1500 that is roughly 1352 bytes of stack overflow from any peer that completes a handshake, before SRS-level streamid or callback auth ever runs.SRT is off by default at runtime, so only deployments that explicitly enable
srt_serverwere exposed.1.5.6 also carries three hardening fixes (upstream PRs #3324, #3320, #3322) for out-of-bounds reads in LOSSREPORT and DROPREQ parsing and a drop-range guard in
CRcvBuffer::dropMessage. These matter less in SRS — the two OOB reads land inside the allocated packet slot, and thedropMessageguard is unreachable under SRS defaults.Full reachability analysis: #4727 (comment)