Claude: Upgrade libsrt to 1.5.6 for security enhancement. v8.0.29 - #4729
Merged
Conversation
Replace the vendored srt-1-fit tree with upstream SRT v1.5.6 to pick up two remotely reachable security fixes and three hardening changes: - 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. - Upstream PR ossrs#3324, #3320, ossrs#3322: OOB reads in LOSSREPORT range parsing and DROPREQ payload parsing, plus a CRcvBuffer::dropMessage range guard. Both CVEs were reachable against a default SRS build with srt_server enabled. 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. The fit tree was 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. Update trunk/3rdparty/README.md and the C++ server code map for the new version, the new Botan crypto backend, and the fit's provenance. Verified: configure builds libsrt reporting SRT_VERSION_STRING "1.5.6", the api.cpp patch applies with no offset, make completes, the srs binary carries the fixed code, and srt_server binds UDP 10080. --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
winlinvip
changed the title
winlinvip
changed the title
winlinvip
changed the title
winlinvip
changed the title
winlinvip
changed the title
winlinvip
added a commit
to winlinvip/srs
that referenced
this pull request
Aug 20, 2026
…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
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, #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 the `dropMessage` guard is unreachable under SRS defaults. Full reachability analysis: #4727 (comment) --- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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>
winlinvip
added a commit
that referenced
this pull request
Aug 20, 2026
) Upgrade the vendored SRT library from 1.5.3 to 1.5.6 to fix two remotely reachable security vulnerabilities. Fixes #4727. SRS vendored SRT 1.5.3 on all maintained branches. Both CVEs fixed in upstream 1.5.6 were confirmed reachable in SRS, not merely present by version number: - **CVE-2026-55869** (upstream PR #3317) — `processSrtMsg_KMREQ` copied `bytelen/4` words into a 104-byte stack buffer with no capacity check. The existing `bytelen <= HCRYPT_MSG_KM_OFS_SALT` test is a lower bound and runs *after* the copy. - **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 and reaches both handlers on any established connection. With the default MSS of 1500, that is roughly **1352 bytes of stack overflow** from any peer that completes a handshake — and SRS's streamid and callback auth run after `srt_accept` returns, so they do not gate it. SRT is off by default at runtime (`get_srt_enabled()` returns false and stock `conf/srs.conf` has no `srt_server` block), so only deployments that explicitly enable `srt_server` were exposed. 1.5.6 also carries three hardening changes (upstream PRs #3324, #3320, out-of-bounds reads land inside the same 1500-byte unit slot allocated by `CUnitQueue::allocateEntry`, making them stale-data logic bugs rather than memory-safety violations, and the `CRcvBuffer::dropMessage` guard is unreachable under SRS defaults because its caller sits behind `!m_bTLPktDrop || !m_bTsbPd`. Full reachability analysis: #4727 (comment) --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
winlinvip
added a commit
to winlinvip/srs
that referenced
this pull request
Aug 20, 2026
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>
winlinvip
added a commit
that referenced
this pull request
Aug 20, 2026
…0.192 (#4732) 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: - **CVE-2026-55869** (upstream PR #3317) — `processSrtMsg_KMREQ` copied `bytelen/4` words into a 104-byte stack buffer with no capacity check. The existing `bytelen <= HCRYPT_MSG_KM_OFS_SALT` test is a lower bound and runs *after* the copy. - **CVE-2026-55868** (upstream PR #3319) — `processSrtMsg_KMRSP` did the same with no validation of `len` at all. The enforced-encryption gate in `interpretSrtHandshake` covers the handshake path, but not the post-connect `UMSG_EXT` control 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 stock `conf/srs.conf` has no `srt_server` block), so only deployments that explicitly enable `srt_server` were 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) --- 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.
Upgrade the vendored SRT library from 1.5.3 to 1.5.6 to fix two remotely reachable security vulnerabilities.
Fixes #4727.
SRS vendored SRT 1.5.3 on all maintained branches. 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
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 and reaches both handlers on any established connection. With the default MSS of 1500, that is roughly 1352 bytes of stack overflow from any peer that completes a handshake — and SRS's streamid and callback auth run aftersrt_acceptreturns, so they do not gate it.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). These matter less in SRS: the LOSSREPORT and DROPREQ out-of-bounds reads land inside the same 1500-byte unit slot allocated by
CUnitQueue::allocateEntry, making them stale-data logic bugs rather than memory-safety violations, and theCRcvBuffer::dropMessageguard is unreachable under SRS defaults because its caller sits behind!m_bTLPktDrop || !m_bTsbPd.Full reachability analysis: #4727 (comment)