* join/begin mrp protocol for attributes of mvrp and msrp within stream_activate.
* Creation of the attribute done on stream creation during es_buidler
Memory Safety: High
The netjack2_recv_opus() and netjack2_recv_int() functions had two
issues:
1. Missing recv length validation: after recv(), neither function
checked that the received data was at least sizeof(header) bytes.
A short packet would cause the pointer to advance past received
data, reading uninitialized VLA memory into the encoded buffer.
2. Integer overflow in bounds check: the expression
(active_ports-1)*max_encoded + sub_cycle*sub_period_bytes + data_size
uses sub_cycle from the network packet header. A large sub_cycle
value can overflow the uint32_t multiplication, wrapping around to
a small value and bypassing the encoded_size bounds check, leading
to an out-of-bounds write into encoded_data.
Additionally, validate that the received data is large enough for the
active_ports * data_size memcpy to prevent reading past the buffer.
Fix by adding recv length checks, using spa_overflow_mul/add for the
bounds arithmetic, and validating recv'd data covers the copy region.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Input Validation: High
The on_socket_data() handler only checked that the received packet was
at least avb_packet_header size before casting to avb_packet_iec61883,
which is larger. A packet between these two sizes would cause
out-of-bounds reads when accessing iec61883 fields like data_len.
Additionally, handle_iec61883_packet() used the data_len field from the
packet to determine how many bytes to copy into the ring buffer without
checking that the claimed data_len didn't exceed the actual received
data. A crafted packet with an inflated data_len could cause an
out-of-bounds read from the receive buffer.
Fix by requiring the minimum packet size to cover both the ethernet
header and the iec61883 header, and by validating that the claimed
payload size doesn't exceed the received data length.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Input Validation: High
The avb_mrp_parse_packet() function, used by both MSRP and MVRP
protocol handlers, had several missing bounds checks:
1. No minimum length validation: the parser began accessing packet
data at sizeof(avb_packet_mrp) without checking len was large
enough, causing out-of-bounds reads on truncated packets.
2. Unsafe loop terminator checks: the while loops checked m[0] and
m[1] without ensuring at least 2 bytes remained in the buffer.
3. Missing hdr_size bounds check: the header size returned by the
check_header callback was used to advance the pointer without
verifying it stayed within the packet bounds.
Fix by adding a minimum packet length check, using structure-size-aware
bounds checks in loop conditions, and validating hdr_size against
remaining packet data before advancing the pointer.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Input Validation: High
The maap_message() handler cast the incoming network data directly to
avb_packet_maap without checking that the received data was at least
sizeof(avb_packet_maap) bytes. The caller only validates the packet is
at least avb_packet_header size, which is smaller. A truncated MAAP
packet could cause out-of-bounds reads when accessing request_start,
request_count, conflict_start, and conflict_count fields in the probe
and defend handlers.
Fix by adding a minimum packet length check at the beginning of
maap_message().
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Input Validation: High
The adp_message() handler accessed avb_ethernet_header and
avb_packet_adp fields from network packet data without checking that
the packet was large enough to contain these structures. A truncated
ADP packet could cause out-of-bounds reads when accessing entity_id,
message_type, and other header fields.
Fix by adding a minimum packet length check before any field access.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Input Validation: High
The acmp_message() handler accessed fields of avb_ethernet_header and
avb_packet_acmp from network packet data without first checking that
the received packet was large enough to contain these structures.
A short packet could cause out-of-bounds reads when accessing packet
header fields.
The VLA-based reply buffers in reply_not_supported(),
handle_connect_tx_command(), and handle_disconnect_tx_command() also
lacked an upper bound on the packet length, allowing a packet claiming
a very large size to cause excessive stack allocation.
Fix by adding minimum length (sizeof(header) + sizeof(acmp)) and
maximum length (MTU) validation at the entry point before any field
access or buffer allocation.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Input Validation: High
The Apple MIDI command parser in module-rtp-session had two issues:
1. Insufficient minimum length check: the caller validated len >= 12,
but struct rtp_apple_midi is 16 bytes (cmd + protocol + initiator +
ssrc). Accessing hdr->ssrc on a 12-byte packet reads 4 bytes past
the received data.
2. Missing null-termination check: the name field (flexible array
member) from the network packet was passed directly to pw_log_info
with %s format and to find_session_by_addr_name for string
comparison, without verifying it contains a null terminator within
the received data. This could read past the receive buffer into
uninitialized stack memory, potentially leaking data into logs.
Fix by adding a sizeof check in parse_apple_midi_cmd and by validating
that the name is null-terminated within the received data in
parse_apple_midi_cmd_in.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Input Validation: Low
The log messages for short timing and control packets used sizeof(bytes)
(size of the ssize_t variable, always 8 on 64-bit) instead of
sizeof(packet) (the actual expected packet size). This caused misleading
log output that could mask packet truncation attacks or debugging issues
with RAOP timing/control packet validation.
Fix by using sizeof(packet) to correctly report the expected packet size.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
