Hello, I've prepared srt 1.5.1-1+deb12u2 for bookworm-security, and it's ready for review.
DSA-6450-1 shipped this fix in srt 1.5.4-1+deb13u1 in Trixie, and srt 1.5.7-1 in Sid is past the upstream 1.5.6 release that contains it. The debdiff against 1.5.1-1+deb12u1 is attached, and so is the draft DLA. - CVE-2026-55868: https://github.com/Haivision/srt/security/advisories/GHSA-4mc6-qmpp-g7gw - CVE-2026-55869: https://github.com/Haivision/srt/security/advisories/GHSA-6xg9-784j-24rm The upload builds both the OpenSSL library and the GnuTLS library from the same patches. Each one exports one extra C++ logging helper that a new log line pulled in. The srt_* entry points match libsrt 1.5.1-1+deb12u1. For testing, I built this in a Bookworm schroot. On 1.5.1-1+deb12u1, an oversized keying-material request (KMREQ) and an oversized keying-material response (KMRSP) write past the stack buffer in the host-to-network copy (HtoNLA). AddressSanitizer reports that as a stack-buffer-overflow. A forged KMREQ on a socket that is already secured moves it to NOSECRET (no secret is available for the keying material), so the next payload comes back as garbage. On 1.5.1-1+deb12u2, those control packets are rejected and the socket stays secured. A clear data packet is counted and dropped, and the encrypted payload after it still arrives. srt-file-transmit copied a 128 KiB file in the clear, and again with a passphrase, on both the OpenSSL build and the GnuTLS build. The bytes matched. ffmpeg 7:5.1.9-0+deb12u1 and gstreamer1.0-plugins-bad 1.22.0-4+deb12u8 were linked to the patched GnuTLS library and carried media over Secure Reliable Transport (SRT). vlc-plugin-access-extra 3.0.24-0+deb12u1 loaded that same library, and a listener with a passphrase rejected an unencrypted caller. The sbuild test suite passed 216 tests on the OpenSSL build and 216 tests on the GnuTLS build. The programs I ran were srt-file-transmit, ffmpeg, GStreamer, and VLC's SRT plugin. obs-studio 29.0.2+dfsg-1 links libsrt1.5-openssl, and nageru 2.2.1 links libsrt1.5-gnutls. Here is my Salsa fork: https://salsa.debian.org/tsimonq2/libsrt/-/tree/bookworm Here is the Debusine work request: https://debusine.debian.net/debian/developers/work-request/1589404/ Feedback is welcome. If nothing showstopping comes up, I'll upload this and issue the DLA on Tuesday afternoon (November 10th, 2026). Best regards, Simon Quigley [email protected]
------------------------------------------------------------------------- Debian LTS Advisory DLA-XXXX-1 [email protected] https://www.debian.org/lts/security/ Simon Quigley November 10, 2026 https://wiki.debian.org/LTS ------------------------------------------------------------------------- Package : srt Version : 1.5.1-1+deb12u2 CVE ID : CVE-2026-55868 CVE-2026-55869 srt is a latency-aware UDP streaming library. Programs that send or receive live video over the Secure Reliable Transport (SRT) protocol use it. A remote attacker who can reach an SRT socket can crash the process using that socket. When the socket is carrying an encrypted stream, that attacker can also make the receiver accept clear packets, so the live stream can be replaced or interrupted. CVE-2026-55868 A keying-material request (KMREQ) that failed to install a key moved an already secured receiver into a failed encryption state. A clear data packet was then stored for playback. CVE-2026-55869 A KMREQ or keying-material response (KMRSP) control packet was copied into a fixed-size stack buffer using the length carried in the packet. An oversized packet writes past the end of that buffer. For Debian 12 bookworm, these problems have been fixed in version 1.5.1-1+deb12u2. We recommend that you upgrade your srt packages. For the detailed security status of srt please refer to its security tracker page at: https://security-tracker.debian.org/tracker/srt Further information about Debian LTS security advisories, how to apply these updates to your system, and frequently asked questions can be found at: https://wiki.debian.org/LTS
diff -Nru srt-1.5.1/debian/changelog srt-1.5.1/debian/changelog --- srt-1.5.1/debian/changelog 2024-11-08 08:09:06.000000000 -0600 +++ srt-1.5.1/debian/changelog 2026-11-06 09:52:27.000000000 -0600 @@ -1,3 +1,11 @@ +srt (1.5.1-1+deb12u2) bookworm-security; urgency=high + + * Non-maintainer upload by the LTS Team. + * CVE-2026-55869: Reject an oversized KMREQ or KMRSP before the stack copy. + * CVE-2026-55868: Ignore a forged key refresh on a secured session. + + -- Simon Quigley <[email protected]> Fri, 06 Nov 2026 09:52:27 -0600 + srt (1.5.1-1+deb12u1) bookworm; urgency=medium * [1e9db13] d/control: correct hard dependencies for dev packages. diff -Nru srt-1.5.1/debian/patches/CVE-2026-55868-d17cc7b4.patch srt-1.5.1/debian/patches/CVE-2026-55868-d17cc7b4.patch --- srt-1.5.1/debian/patches/CVE-2026-55868-d17cc7b4.patch 1969-12-31 18:00:00.000000000 -0600 +++ srt-1.5.1/debian/patches/CVE-2026-55868-d17cc7b4.patch 2026-11-06 09:52:27.000000000 -0600 @@ -0,0 +1,304 @@ +Origin: https://github.com/Haivision/srt/commit/d17cc7b4dbe4658eb3ac71c7eec3c71780553250 +Reviewed-by: Simon Quigley <[email protected]> +Last-Update: 2026-11-05 + +Backported to 1.5.1. Net of d17cc7b4, +e02c8b0785e2771103003fa16fe8a2033ff19605 (restore the previous KEK +when unwrap fails), 80d7f419360e5ec620f77da43c9333daacfd4df5 (one +failure state), and 78e7e144bb49b70fc1c20b44e9aa1f5705919e3e (a failed +refresh sends no KMRSP). 15a7c6f79af572b84740745339deb0cfbd881c58 +removed a key-index check that d17cc7b4 had added; that check is not +included. 1.5.1 has no AES-GCM. + +From d17cc7b4dbe4658eb3ac71c7eec3c71780553250 Mon Sep 17 00:00:00 2001 +From: Mikolaj Malecki <[email protected]> +Date: Fri, 5 Jun 2026 14:09:18 +0200 +Subject: [PATCH] Mimimum patch to fix spoofed MKREQ failure + + +diff --git a/srtcore/crypto.cpp b/srtcore/crypto.cpp +index 4740102..8703d0b 100644 +--- a/srtcore/crypto.cpp ++++ b/srtcore/crypto.cpp +@@ -139,17 +139,14 @@ int srt::CCryptoControl::processSrtMsg_KMREQ( + // what has called this function. The HSv5 handshake only enforces bidirectional + // connection. + +- bool bidirectional = hsv > CUDT::HS_VERSION_UDT4; +- +- // Local macro to return rejection appropriately. +- // CHANGED. The first version made HSv5 reject the connection. +- // This isn't well handled by applications, so the connection is +- // still established, but unable to handle any transport. +-//#define KMREQ_RESULT_REJECTION() if (bidirectional) { return SRT_CMD_NONE; } else { w_srtlen = 1; goto HSv4_ErrorReport; } +-#define KMREQ_RESULT_REJECTION() { w_srtlen = 1; goto HSv4_ErrorReport; } ++ const bool bidirectional = hsv > CUDT::HS_VERSION_UDT4; ++ // A context already exists once the first KMREQ has been accepted. ++ // A later KMREQ is a key refresh. Failure on that path must not move ++ // an established SECURED receiver to BADSECRET. ++ const bool kmx_update = m_hRcvCrypto; ++ SRT_KM_STATE failure_state = m_KmSecret.len == 0 ? SRT_KM_S_NOSECRET : SRT_KM_S_BADSECRET; + +- int rc = HAICRYPT_OK; // needed before 'goto' run from KMREQ_RESULT_REJECTION macro +- bool wasb4 SRT_ATR_UNUSED = false; ++ int rc = HAICRYPT_OK; + size_t sek_len = 0; + + // What we have to do: +@@ -162,8 +159,7 @@ int srt::CCryptoControl::processSrtMsg_KMREQ( + if ( bytelen <= HCRYPT_MSG_KM_OFS_SALT ) //Sanity on message + { + LOGC(cnlog.Error, log << "processSrtMsg_KMREQ: size of the KM (" << bytelen << ") is too small, must be >" << HCRYPT_MSG_KM_OFS_SALT); +- m_RcvKmState = SRT_KM_S_BADSECRET; +- KMREQ_RESULT_REJECTION(); ++ goto HSv4_ErrorReport; + } + + HLOGC(cnlog.Debug, log << "KMREQ: getting SEK and creating receiver crypto"); +@@ -171,8 +167,13 @@ int srt::CCryptoControl::processSrtMsg_KMREQ( + if ( sek_len == 0 ) + { + LOGC(cnlog.Error, log << "processSrtMsg_KMREQ: Received SEK is empty - REJECTING!"); +- m_RcvKmState = SRT_KM_S_BADSECRET; +- KMREQ_RESULT_REJECTION(); ++ goto HSv4_ErrorReport; ++ } ++ ++ if (kmx_update && m_iRcvKmKeyLen != sek_len) ++ { ++ LOGC(cnlog.Error, log << "processSrtMsg_KMREQ: KMX refresh came in with a DIFFERENT KEY LEN: " << sek_len); ++ goto HSv4_ErrorReport; + } + + // Write the key length +@@ -194,59 +195,59 @@ int srt::CCryptoControl::processSrtMsg_KMREQ( + if (m_KmSecret.len == 0) //We have a shared secret <==> encryption is on + { + LOGC(cnlog.Warn, log << "processSrtMsg_KMREQ: Agent does not declare encryption - won't decrypt incoming packets!"); +- m_RcvKmState = SRT_KM_S_NOSECRET; +- KMREQ_RESULT_REJECTION(); ++ failure_state = SRT_KM_S_NOSECRET; ++ goto HSv4_ErrorReport; + } +- wasb4 = m_hRcvCrypto; + + if (!createCryptoCtx(m_iRcvKmKeyLen, HAICRYPT_CRYPTO_DIR_RX, (m_hRcvCrypto))) + { + LOGC(cnlog.Error, log << "processSrtMsg_KMREQ: Can't create RCV CRYPTO CTX - must reject..."); +- m_RcvKmState = SRT_KM_S_NOSECRET; +- KMREQ_RESULT_REJECTION(); ++ failure_state = SRT_KM_S_NOSECRET; ++ goto HSv4_ErrorReport; + } + +- if (!wasb4) ++ if (!kmx_update) + { + HLOGC(cnlog.Debug, log << "processSrtMsg_KMREQ: created RX ENC with KeyLen=" << m_iRcvKmKeyLen); ++ // We have both sides set with password, so both are pending for security. ++ // Do this only for the first KMREQ. A refresh must stay SECURED until ++ // the new key is actually installed. ++ m_RcvKmState = SRT_KM_S_SECURING; + } +- // We have both sides set with password, so both are pending for security +- m_RcvKmState = SRT_KM_S_SECURING; +- // m_SndKmState is set to SECURING or UNSECURED in init(), +- // or it might have been set to SECURED, NOSECRET or BADSECRET in the previous +- // handshake iteration (handshakes may be sent multiple times for the same connection). + + rc = HaiCrypt_Rx_Process(m_hRcvCrypto, kmdata, bytelen, NULL, NULL, 0); +- switch(rc >= 0 ? HAICRYPT_OK : rc) +- { +- case HAICRYPT_OK: +- m_RcvKmState = SRT_KM_S_SECURED; +- HLOGC(cnlog.Debug, log << "KMREQ/rcv: (snd) Rx process successful - SECURED."); +- //Send back the whole message to confirm +- break; +- case HAICRYPT_ERROR_WRONG_SECRET: //Unmatched shared secret to decrypt wrapped key +- m_RcvKmState = m_SndKmState = SRT_KM_S_BADSECRET; +- //Send status KMRSP message to tel error +- w_srtlen = 1; +- LOGC(cnlog.Warn, log << "KMREQ/rcv: (snd) Rx process failure - BADSECRET"); +- break; +- case HAICRYPT_ERROR: //Other errors +- default: +- m_RcvKmState = m_SndKmState = SRT_KM_S_NOSECRET; +- w_srtlen = 1; +- LOGC(cnlog.Warn, log << "KMREQ/rcv: (snd) Rx process failure (IPE) - NOSECRET"); +- break; +- } +- +- LOGP(cnlog.Note, FormatKmMessage("processSrtMsg_KMREQ", SRT_CMD_KMREQ, bytelen)); + + // Since now, when CCryptoControl::decrypt() encounters an error, it will print it, ONCE, + // until the next KMREQ is received as a key regeneration. + m_bErrorReported = false; + ++ if (rc >= 0) ++ { ++ m_RcvKmState = SRT_KM_S_SECURED; ++ HLOGC(cnlog.Debug, log << "KMREQ/rcv: (snd) Rx process successful - SECURED."); ++ //Send back the whole message to confirm ++ } ++ else ++ { ++ switch (rc) ++ { ++ case HAICRYPT_ERROR_WRONG_SECRET: //Unmatched shared secret to decrypt wrapped key ++ failure_state = SRT_KM_S_BADSECRET; ++ LOGC(cnlog.Warn, log << "KMREQ/rcv: (snd) Rx process failure - BADSECRET"); ++ break; ++ case HAICRYPT_ERROR: //Other errors ++ default: ++ failure_state = SRT_KM_S_NOSECRET; ++ LOGC(cnlog.Warn, log << "KMREQ/rcv: (snd) Rx process failure (IPE) - NOSECRET"); ++ break; ++ } + +- if (w_srtlen == 1) ++ if (!kmx_update) ++ m_SndKmState = failure_state; + goto HSv4_ErrorReport; ++ } ++ ++ LOGP(cnlog.Note, FormatKmMessage("processSrtMsg_KMREQ", SRT_CMD_KMREQ, bytelen)); + + // Configure the sender context also, if it succeeded to configure the + // receiver context and we are using bidirectional mode. +@@ -304,6 +305,13 @@ int srt::CCryptoControl::processSrtMsg_KMREQ( + + HSv4_ErrorReport: + ++ // A refresh of an existing association must leave the current state ++ // alone. Returning no KMRSP matters: announcing BADSECRET is how a ++ // forged KMREQ used to make the receiver take unencrypted packets. ++ if (kmx_update) ++ return SRT_CMD_NONE; ++ ++ m_RcvKmState = failure_state; + if (bidirectional && hasPassphrase()) + { + // If the Forward KMX process has failed, the reverse-KMX process was not done at all. +@@ -312,7 +320,6 @@ HSv4_ErrorReport: + // Create the "fake crypto" with the passphrsae you currently have. + createFakeSndContext(); + } +-#undef KMREQ_RESULT_REJECTION + + #else + // It's ok that this is reported as error because this happens in a scenario, +diff --git a/haicrypt/hcrypt_ctx_rx.c b/haicrypt/hcrypt_ctx_rx.c +index 9bd8a8e..707021b 100644 +--- a/haicrypt/hcrypt_ctx_rx.c ++++ b/haicrypt/hcrypt_ctx_rx.c +@@ -128,19 +128,22 @@ int hcryptCtx_Rx_ParseKM(hcrypt_Session *crypto, unsigned char *km_msg, size_t m + return(-1); + } + ++ /* Apply salt, SEK length, and KEK on a copy. Commit only after unwrap ++ * succeeds, so a forged KMREQ cannot replace the keys of a secured session. */ ++ hcrypt_Ctx new_ctx = *ctx; + /* Check Salt and get if new */ +- if ((salt_len != ctx->salt_len) +- || (0 != memcmp(ctx->salt, &km_msg[HCRYPT_MSG_KM_OFS_SALT], salt_len))) { ++ if ((salt_len != new_ctx.salt_len) ++ || (0 != memcmp(new_ctx.salt, &km_msg[HCRYPT_MSG_KM_OFS_SALT], salt_len))) { + /* Salt changed (or 1st KMmsg received) */ +- memcpy(ctx->salt, &km_msg[HCRYPT_MSG_KM_OFS_SALT], salt_len); +- ctx->salt_len = salt_len; ++ memcpy(new_ctx.salt, &km_msg[HCRYPT_MSG_KM_OFS_SALT], salt_len); ++ new_ctx.salt_len = salt_len; + do_pbkdf = 1; /* Impact on password derived kek */ + } + + /* Check SEK length and get if new */ +- if (sek_len != ctx->sek_len) { ++ if (sek_len != new_ctx.sek_len) { + /* Key length changed or 1st KMmsg received */ +- ctx->sek_len = sek_len; ++ new_ctx.sek_len = sek_len; + do_pbkdf = 1; /* Impact on password derived kek */ + } + +@@ -148,21 +151,32 @@ int hcryptCtx_Rx_ParseKM(hcrypt_Session *crypto, unsigned char *km_msg, size_t m + * Regenerate KEK if it is password derived + * and Salt or SEK length changed + */ +- if (ctx->cfg.pwd_len && do_pbkdf) { +- if (hcryptCtx_GenSecret(crypto, ctx)) { ++ int rollback_kek = 0; ++ if (new_ctx.cfg.pwd_len && do_pbkdf) { ++ if (hcryptCtx_GenSecret(crypto, &new_ctx)) { + return(-1); + } +- ctx->status = HCRYPT_CTX_S_SARDY; ++ new_ctx.status = HCRYPT_CTX_S_SARDY; + kek_len = sek_len; /* KEK changed */ ++ rollback_kek = 1; + } + + /* Unwrap SEK(s) and set in context */ +- if (0 > crypto->cryspr->km_unwrap(crypto->cryspr_cb, seks, +- &km_msg[HCRYPT_MSG_KM_OFS_SALT + salt_len], +- (sek_cnt * sek_len) + HAICRYPT_WRAPKEY_SIGN_SZ)) { +- HCRYPT_LOG(LOG_WARNING, "%s", "unwrap key failed\n"); +- return(-2); //Report unmatched shared secret ++ { ++ unsigned int msglen = (sek_cnt * sek_len) + HAICRYPT_WRAPKEY_SIGN_SZ; ++ int wrc = crypto->cryspr->km_unwrap(crypto->cryspr_cb, seks, ++ &km_msg[HCRYPT_MSG_KM_OFS_SALT + salt_len], ++ msglen); ++ if (wrc < 0) { ++ HCRYPT_LOG(LOG_WARNING, "%s%s\n", "unwrap key failed - internal KEK: ", rollback_kek ? "ROLLBACK" : "unchanged"); ++ /* GenSecret installs the KEK into the session. On failure, put the ++ * previous KEK back. The live context itself was not modified. */ ++ if (rollback_kek) ++ hcryptCtx_GenSecret(crypto, ctx); ++ return(-2); //Report unmatched shared secret ++ } + } ++ *ctx = new_ctx; + /* + * First SEK in KMmsg is eSEK if both SEK present + */ +diff --git a/haicrypt/hcrypt_rx.c b/haicrypt/hcrypt_rx.c +index e77c73b..d0d6cc3 100644 +--- a/haicrypt/hcrypt_rx.c ++++ b/haicrypt/hcrypt_rx.c +@@ -99,6 +99,11 @@ int HaiCrypt_Rx_Process(HaiCrypt_Handle hhc, + HCRYPT_LOG(LOG_ERR, "%s", "cryspr had no decryptor\n"); + nbout = -1; + } else if (ctx->status >= HCRYPT_CTX_S_KEYED) { ++ if ((int)in_len <= crypto->msg_info->pfx_len) ++ { ++ HCRYPT_LOG(LOG_ERR, "%s%d", "Invalid enc data packet: ", (int)in_len); ++ return -1; ++ } + hcrypt_DataDesc indata; + indata.pfx = in_msg; + indata.payload = &in_msg[crypto->msg_info->pfx_len]; +diff --git a/srtcore/core.cpp b/srtcore/core.cpp +index 93224f4..807caf6 100644 +--- a/srtcore/core.cpp ++++ b/srtcore/core.cpp +@@ -10145,6 +10145,20 @@ int srt::CUDT::processData(CUnit* in_unit) + } + } + ++ // An encrypted session (anything but UNSECURED) must not accept a ++ // clear packet. A forged KMREQ used to move SECURED to BADSECRET, ++ // after which a clear packet was stored and delivered. ++ if (u->m_Packet.getMsgCryptoFlags() == EK_NOENC ++ && m_pCryptoControl ++ && m_pCryptoControl->m_RcvKmState != SRT_KM_S_UNSECURED) ++ { ++ HLOGC(qrlog.Debug, log << CONID() << "Packet not encrypted, dropping data."); ++ IF_HEAVY_LOGGING(exc_type = "UNENCRYPTED"); ++ ScopedLock lg(m_StatsLock); ++ m_stats.rcvr.undecrypted.count(stats::BytesPackets(pktsz, 1)); ++ continue; ++ } ++ + bool adding_successful = true; + #if ENABLE_NEW_RCVBUFFER + if (m_pRcvBuffer->insert(u) < 0) diff -Nru srt-1.5.1/debian/patches/CVE-2026-55869-05708112.patch srt-1.5.1/debian/patches/CVE-2026-55869-05708112.patch --- srt-1.5.1/debian/patches/CVE-2026-55869-05708112.patch 1969-12-31 18:00:00.000000000 -0600 +++ srt-1.5.1/debian/patches/CVE-2026-55869-05708112.patch 2026-11-06 09:52:27.000000000 -0600 @@ -0,0 +1,39 @@ +Origin: https://github.com/Haivision/srt/commit/0570811260a9d1e353c4ec85218fe65ab6bd2644 +Reviewed-by: Simon Quigley <[email protected]> +Last-Update: 2026-11-05 + +Backported to 1.5.1. The length check is unchanged. 1.5.1 has no +test/test_crypto.cpp, so the unit test from this commit is not included. +processSrtMsg_KMRSP still takes the handshake version as its third argument. + +From 0570811260a9d1e353c4ec85218fe65ab6bd2644 Mon Sep 17 00:00:00 2001 +From: Matthew Szatmary <[email protected]> +Date: Fri, 15 May 2026 14:17:27 -0700 +Subject: [PATCH] [BUG] Validate KMRSP wire length to prevent stack overflow + + +diff --git a/srtcore/crypto.cpp b/srtcore/crypto.cpp +index 4740102..8703d0b 100644 +--- a/srtcore/crypto.cpp ++++ b/srtcore/crypto.cpp +@@ -330,6 +330,20 @@ HSv4_ErrorReport: + + int srt::CCryptoControl::processSrtMsg_KMRSP(const uint32_t* srtdata, size_t len, int /* XXX unused? hsv*/) + { ++ // Validate the wire-supplied length before using it: ++ // - oversize would overflow the fixed-size stack buffer below; ++ // - non-word-aligned or too-small payloads are malformed by protocol and would ++ // feed uninitialised stack into downstream key-matching logic. ++ if (len > SRT_CMD_MAXSZ ++ || len < sizeof(uint32_t) ++ || (len % sizeof(uint32_t)) != 0) ++ { ++ LOGC(cnlog.Error, log << "processSrtMsg_KMRSP: malformed len " << len ++ << " (must be a non-zero multiple of " << sizeof(uint32_t) ++ << ", up to " << SRT_CMD_MAXSZ << ") - rejecting"); ++ return SRT_CMD_NONE; ++ } ++ + /* All 32-bit msg fields (if present) swapped on reception + * But HaiCrypt expect network order message + * Re-swap to cancel it. diff -Nru srt-1.5.1/debian/patches/CVE-2026-55869-e020c3bb.patch srt-1.5.1/debian/patches/CVE-2026-55869-e020c3bb.patch --- srt-1.5.1/debian/patches/CVE-2026-55869-e020c3bb.patch 1969-12-31 18:00:00.000000000 -0600 +++ srt-1.5.1/debian/patches/CVE-2026-55869-e020c3bb.patch 2026-11-06 09:52:27.000000000 -0600 @@ -0,0 +1,31 @@ +Origin: https://github.com/Haivision/srt/commit/e020c3bb8e04e204b36f9fb56cdcbb6756cd0d28 +Reviewed-by: Simon Quigley <[email protected]> +Last-Update: 2026-11-05 + +Backported to 1.5.1. The check rejects the KMREQ before HtoNLA copies it +into the caller's fixed stack buffer. + +From e020c3bb8e04e204b36f9fb56cdcbb6756cd0d28 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Cl=C3=A9ment=20G=C3=A9rouville?= <[email protected]> +Date: Thu, 25 Jun 2026 17:22:30 +0200 +Subject: [PATCH] Fix KMREQ buffer overflow at the right place. + + +diff --git a/srtcore/crypto.cpp b/srtcore/crypto.cpp +index 4740102..8703d0b 100644 +--- a/srtcore/crypto.cpp ++++ b/srtcore/crypto.cpp +@@ -131,6 +131,13 @@ int srt::CCryptoControl::processSrtMsg_KMREQ( + * Re-swap to cancel it. + */ + #ifdef SRT_ENABLE_ENCRYPTION ++ // Reject before HtoNLA. The caller passes a stack buffer of SRTDATA_MAXSIZE ++ // words (processSrtMsg), and an oversized or misaligned KMREQ writes past it. ++ if (bytelen % sizeof(uint32_t) != 0 || bytelen > HCRYPT_MSG_KM_MAX_SZ) ++ { ++ LOGC(cnlog.Error, log << "processSrtMsg_KMREQ: size of the KM (" << bytelen << ") is too high, must be < " << HCRYPT_MSG_KM_MAX_SZ); ++ return SRT_CMD_NONE; ++ } + w_srtlen = bytelen/sizeof(srtdata[SRT_KMR_KMSTATE]); + HtoNLA((pw_srtdata_out), srtdata, w_srtlen); + unsigned char* kmdata = reinterpret_cast<unsigned char*>(pw_srtdata_out); diff -Nru srt-1.5.1/debian/patches/series srt-1.5.1/debian/patches/series --- srt-1.5.1/debian/patches/series 2022-07-02 04:10:44.000000000 -0500 +++ srt-1.5.1/debian/patches/series 2026-11-06 09:52:27.000000000 -0600 @@ -1,2 +1,5 @@ 001-multiarch-rpath.patch test_failures.patch +CVE-2026-55869-05708112.patch +CVE-2026-55869-e020c3bb.patch +CVE-2026-55868-d17cc7b4.patch
OpenPGP_signature.asc
Description: OpenPGP digital signature
