security: fix infinite loop via MSG_PEEK on mismatched NetJack2 packets

Memory Safety: High

When netjack2_recv_data() receives a packet that doesn't match the
expected data_stream or id, it logs "not our packet" and continues the
loop. However, since the previous recv() used MSG_PEEK, the packet is
not consumed from the socket buffer. This causes the loop to spin
indefinitely on the same mismatched packet, consuming 100% CPU.

A remote attacker on the same network can trigger this by sending a
single crafted NetJack2 packet with a mismatched stream or id field,
causing a denial of service on the audio processing thread.

Fix by consuming (discarding) the mismatched packet with a non-peeking
recv() before continuing the loop.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Wim Taymans 2026-04-27 12:13:55 +02:00
parent daa66c0646
commit 8ed6fe5edf

View file

@ -1040,7 +1040,9 @@ static int netjack2_recv_data(struct netjack2_peer *peer,
if (ntohl(header.data_stream) != peer->other_stream || if (ntohl(header.data_stream) != peer->other_stream ||
ntohl(header.id) != peer->params.id) { ntohl(header.id) != peer->params.id) {
pw_log_debug("not our packet"); uint8_t discard[peer->params.mtu];
pw_log_debug("not our packet, discarding");
recv(peer->fd, discard, sizeof(discard), 0);
continue; continue;
} }