RTCP SR/RR length check ignores the fixed header, report blocks are read past the packet end

从 daemon/rtcp.c 中 rtcp_Xr() 的长度检查开始，并比较 daemon/rtcp.c 和 lib/rtcplib.h 中 RR 与 SR 的布局。检查 rtcp_rr_list() 如何使用声明的包长度，然后更新检查逻辑，使其考虑固定前缀和报告块。完成标准是短 RR 和 SR 示例被拒绝，而有效的 RR 仍被接受。

rtpengine version the issue has been seen with

mr26.3.1.2 (3a3ef61), built from the tag, userspace only. The same code is on master at f950a9f.

Used distribution and its version

Debian 13 (container)

Linux kernel version used

6.8.0-90-generic (kernel module not used)

CPU architecture issue was seen on

aarch64

Expected behaviour you didn't see

An SR or RR packet whose report count (RC) does not fit in its declared length is rejected
("Failed to handle or parse RTCP packet type ...").

Unexpected behaviour you saw

rtcp_Xr() compares the packet length with count * sizeof(struct report_block) only. It
leaves out the 8-byte RR prefix (header + SSRC) and the 28-byte SR prefix (header, SSRC and
sender info) that come before the report blocks:

• daemon/rtcp.c#L519-L523 is the check.
• daemon/rtcp.c#L59-L82 and lib/rtcplib.h#L35-L38 define the layouts.

The only other length check is min_packet_sizes, which ensures just the prefix itself
(L454-L456, L683-L690).

rtcp_rr_list() then walks header.count blocks starting after the prefix
(L525-L551), so it can read past the end of the RTCP packet:

• up to 8 bytes for RR;
• up to 28 bytes for SR.

The bytes it reads are either the next packet of a compound RTCP packet, or the unused tail of
the receive buffer when the SR/RR is the last packet in the datagram. That tail is the
RTP_BUFFER_TAIL_ROOM slack, so the read stays inside the allocation:

• lib/poller.h#L15-L18;
• daemon/media_socket.c#L3951-L3954;
• daemon/media_socket.c#L3682-L3688.

What happens to these bytes:

• scratch_rr copies them into the receiver-report scratch area, so they go into the SSRC
  stats/MOS (mos_rr), the RTCP log and the HEP JSON (homer_rr):
  L972-L983,
  L1058-L1069.
• With SSRC translation active, transcode_rr also writes ssrc, number_lost,
  fraction_lost and high_seq_received back into the same block
  (L1296-L1356).
  For an SR, that block can lie wholly past the packet's declared end.

Steps to reproduce the problem

Start rtpengine with --table=-1 --interface=127.0.0.1 --listen-ng=127.0.0.1:2223 --homer=127.0.0.1:9060 --homer-protocol=udp --homer-id=2001, set up a plain RTP/AVP PCMU call with offer and answer over NG, send a few RTP packets each way, then send these from the caller's RTCP port to rtpengine's RTCP port for it. Every datagram ends with the same APP packet (80 cc 00 02, SSRC 0x33333333, name ABCD). Each report block in the test uses SSRC 0x22222222, fraction lost 1, cumulative lost 5, highest sequence 256, jitter 7, LSR 0x0a0a0a0a and DLSR 0x0b0b0b0b, as far as it fits in the packet:

• RR, length field 5 (24 bytes), RC=1: 81 c9 00 05, SSRC, then 16 bytes.
  • The 8-byte minimum passes, and 24 < 1*24 is false, so the packet is accepted.
  • reports[0] covers bytes 8-31, which is 8 bytes past the end.
• SR, length field 11 (48 bytes), RC=2: 82 c8 00 0b, SSRC, 20 bytes of sender info, then 20 bytes.
  • The 28-byte minimum passes, and 48 < 2*24 is false, so the packet is accepted.
  • The blocks cover bytes 28-75; the second one lies entirely past the end.

For comparison, a valid RR (length field 7, 32 bytes, RC=1) followed by the same APP packet.

Additional program output to the terminal or logs illustrating the issue

The report blocks in the HEP RTCP JSON that rtpengine sent for each datagram:

valid RR, length 7 (32 bytes):
  81 c9 00 07 11 11 11 11 22 22 22 22 01 00 00 05 00 00 01 00 00 00 00 07 0a 0a 0a 0a 0b 0b 0b 0b | 80 cc 00 02 33 33 33 33 41 42 43 44
  {"source_ssrc":572662306,"highest_seq_no":256,"fraction_lost":1,"ia_jitter":7,"packets_lost":5,"lsr":168430090,"dlsr":185273099}

short RR, length 5 (24 bytes), RC=1:
  81 c9 00 05 11 11 11 11 22 22 22 22 01 00 00 05 00 00 01 00 00 00 00 07 | 80 cc 00 02 33 33 33 33 41 42 43 44
  {"source_ssrc":572662306,"highest_seq_no":256,"fraction_lost":1,"ia_jitter":7,"packets_lost":5,"lsr":2160852994,"dlsr":858993459}

short SR, length 11 (48 bytes), RC=2:
  82 c8 00 0b 11 11 11 11 00 00 00 01 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 05 22 22 22 22 01 00 00 05 00 00 01 00 00 00 00 07 0a 0a 0a 0a | 80 cc 00 02 33 33 33 33 41 42 43 44
  {"source_ssrc":572662306,"highest_seq_no":256,"fraction_lost":1,"ia_jitter":7,"packets_lost":5,"lsr":168430090,"dlsr":2160852994},
  {"source_ssrc":858993459,"highest_seq_no":0,"fraction_lost":65,"ia_jitter":0,"packets_lost":4342596,"lsr":0,"dlsr":0}

All three are accepted, and no warning is logged.

• In the short RR, lsr 2160852994 is 0x80cc0002, the APP packet's first word, and dlsr 858993459 is the APP packet's SSRC.
• In the short SR, the second report block lies entirely past the SR. Its source_ssrc is the APP SSRC, its fraction_lost 65 and packets_lost 4342596 are A and BCD from the APP name, and the rest is read from the receive buffer past the end of the datagram (zeros in this run).

With the check below, the two short packets are rejected with Failed to handle or parse RTCP packet type 201 and ... type 200, they produce no HEP report, and the valid RR is unchanged.

Anything else?

Suggested fix: include the fixed part in the check, for example by passing it into
rtcp_Xr():

• RR: el->len < sizeof(struct receiver_report_packet) + count * sizeof(struct report_block);
• SR: the same with sizeof(struct sender_report_packet).