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

Open Beginner friendly
  • Is something wrong?
#2,229 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
c
Domain
networking

Research direction

Start in daemon/rtcp.c at the rtcp_Xr() length check and compare the RR and SR layouts in daemon/rtcp.c and lib/rtcplib.h. Check how rtcp_rr_list() uses the declared packet length, then update the check to account for the fixed prefix and report blocks. Done means the short RR and SR examples are rejected while the valid RR remains accepted.

Written by the indexing model from the issue text.

Description

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:

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:

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).
Dominant language
Perl
Stars
992
Forks
459
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from sipwise/rtpengine

All issues in sipwise/rtpengine

Similar issues

More Perl issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.