The status-packet skip loop in ff_rdt_parse_header() advances the parser by pkt_len = AV_RB16(buf + 3). Commit 0d0373d added a check that pkt_len does not exceed the remaining length, but a pkt_len of zero (or any value below the 5-byte status header) still passes that check while leaving buf and len unchanged. buf[1] then still equals 0xFF, so the while loop makes no progress and spins forever.
A peer that feeds RDT data to the depacketizer (a malicious or broken RealMedia RTSP server) can therefore hang the client with a status packet whose length field is zero. Require the advertised length to cover at least the 5-byte status header so the loop is guaranteed to advance. Reproduced against the current release: ff_rdt_parse_header() no longer returns when handed such a status packet, and returns normally again with this change applied. Builds cleanly; well-formed status packets (length at least 5) are unaffected. Signed-off-by: Michael Bommarito <[email protected]> --- Ancient and obviously not a common format anymore, but still technically shipping. Found via yet another AI-assisted audit and confirmed myself. libavformat/rdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/rdt.c b/libavformat/rdt.c index 77048d5..fda9f0c 100644 --- a/libavformat/rdt.c +++ b/libavformat/rdt.c @@ -206,7 +206,7 @@ ff_rdt_parse_header(const uint8_t *buf, int len, return -1; /* not followed by a data packet */ pkt_len = AV_RB16(buf+3); - if (pkt_len > len) + if (pkt_len < 5 || pkt_len > len) return AVERROR_INVALIDDATA; buf += pkt_len; len -= pkt_len; -- 2.53.0 _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
