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>
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>
Memory Safety: High
The recv_midi function calculated MIDI buffer usage from network packet
fields (event_count, write_pos) using plain arithmetic that could
overflow on 32-bit platforms. A crafted NetJack2 packet with a large
event_count could wrap the size_t multiplication, bypassing the bounds
check and causing out-of-bounds memory access. Replaced with
spa_overflow_mul/spa_overflow_add to detect overflow before use.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Memory Safety: High
The nj2_dump_session_params() function logs char array fields (type,
name, driver_name, follower_name) from network-received
nj2_session_params structs using %s format. These fields are fixed-size
char arrays filled by recvfrom() and are not guaranteed to contain a null
terminator. A malicious peer can send a packet with no null bytes in
these fields, causing pw_log_info to read past the struct boundary,
potentially crashing the process or leaking adjacent heap memory.
Use %.*s format specifier with explicit maximum lengths in the dump
function to bound the string reads. Also force null-terminate the
string fields in nj2_session_params_ntoh() so that all downstream
consumers after byte-order conversion are safe.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Memory Safety: High
In netjack2_init(), several buffer sizes are computed by multiplying
network-provided session parameters (period_size, channel counts,
kbps) without overflow checks. A malicious network peer can send
crafted session parameters that cause these multiplications to
overflow, resulting in undersized buffer allocations. Subsequent
writes to these buffers then overflow the heap.
Specific issues fixed:
1. midi_size = period_size * sizeof(float) * max_midi_channels can
overflow, causing calloc to allocate a small buffer.
2. encoded_size = max_encoded_size * max_audio_channels can overflow
for both INT and OPUS encoders.
3. OPUS kbps * period_size * 1024 numerator can overflow uint32_t;
widen to uint64_t for the intermediate calculation.
4. Division by zero if sample_rate is 0 in OPUS encoder path.
5. Missing NULL checks on calloc for empty and midi_data buffers.
6. Channel counts not capped to MAX_CHANNELS before use.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Memory Safety: High
In netjack2_recv_float(), several values from untrusted network packet
headers are used in arithmetic without overflow protection:
1. active_ports from the network header had no upper bound check. A
very large value causes `active_ports * sub_period_bytes` to
overflow uint32_t, producing a small value that passes the length
check, then the loop iterates out of bounds on the receive buffer.
2. The sub_cycle bounds check `sub_cycle * sub_period_size >
quantum_limit` can overflow, allowing a large sub_cycle to pass
the check and cause an out-of-bounds write when computing the
destination offset.
Fix by capping active_ports to MAX_CHANNELS, casting to size_t for the
length check to prevent overflow, and rewriting the sub_cycle check as
a division to avoid overflow.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Memory Safety: High
In netjack2_recv_midi(), the offset calculation `max_size * sub_cycle`
uses sub_cycle from an untrusted network packet header. A large
sub_cycle value could cause integer overflow, producing a small offset
that passes the subsequent bounds check and leads to an out-of-bounds
write into the MIDI data buffer.
Similarly, the bounds check `offset + len < midi_size` could itself
overflow, and the `used` size calculation from network-controlled
event_count and write_pos fields could overflow to bypass the size
check.
Fix by adding an explicit overflow check before the multiplication,
rewriting the bounds check to use subtraction (which cannot overflow
after the prior check), and adding an underflow check on the `used`
calculation.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add a control.ump port property. When true, the port wants UMP and the
mixer will convert to it. When false, the port supports both UMP and
Midi1 and no conversions will happen. When unset, the mixer will always
convert UMP to midi1.
Remove the CONTROL_types property from the filter. This causes problems
because this is the format negotiated with peers, which might not
support the types but can still be linked because the mixer will
convert.
The control.ump port property is supposed to be a temporary fix until we
can negotiate the mixer ports properly with the CONTROL_types.
Remove UMP handling from bluetooth midi, just use the raw Midi1 events
now that the mixer will give those and we are supposed to output our
unconverted format.
Fix midi events in-place in netjack because we can.
Update docs and pw-mididump to note that we are back to midi1 as the
default format.
With this, most of the midi<->UMP conversion should be gone again and we
should be able to avoid conversion problems in ALSA and PipeWire.
Fixes#5183
Avoid doing conversions in the nodes between Midi formats, just assume
the imput is what we expect and output what we naturally produce.
For ALSA this means we produce and consume Midi1 or Midi2 depending on the
configurtation.
All of the other modules (ffado, RTP, netjack and VBAN) really only
produce and consume MIDI1.
Set the default MIDI format to MIDI1 in ALSA.
Whith this change, almost everything now produces and consumes MIDI1
again (previously the buffer format was forced to MIDI2).
The problem is that MIDI2 to and from MIDI1 conversion has problems in
some cases in PipeWire and ALSA and breaks compatibility with some
hardware.
The idea is to let elements produce their prefered format and that the
control mixer also negotiates and converts to the node prefered format.
There is then a mix of MIDI2 and MIDI1 on ports but with the control
port adapting, this should not be a problem.
There is one remaining problem to make this work, the port format is
taken from the node port and not the mixer port, which would then expose
the prefered format on the port and force negotiation to it with the
peer instead of in the mixer.
See #5183
Improve the spa_ump_to_midi function so that it can consume multiple UMP
messages and produce multiple midi messages.
Some UMP messages (like program changes) need to be translated into up
to 3 midi messages. Do this byt adding a state to the function and by
making it consume the input bytes, just like the spa_ump_from_midi
function.
Adapt code to this new world. This is a little API break..
The midi events have their large data offsets relative to the start of
the buffer and the large data is at the end of the buffer. Because we
copied it down, right after the events, but we didn't adjust the
offsets, calculate a correction offset when unpacking the events.
SysEx in UMP can span multiple packets. In MIDI1 we can't split them up
into multiple events so we need to collect the complete sysex and then
write out the event.
Fixes SysEx writes to ALSA seq by running the event encoder until a
valid packet is completed.
Also fixes split MIDI1 packets in the JACK API when going through the
tunnel or via netjack.
This provides access to GNU C library-style endian and byteswap functions.
Windows doesn't provide pre-processor defines for endianness, but
all current Windows architectures (X32, X64, ARM) are little-endian.
The module advertizes itself on multicast and will trigger a new client
in the netjack2 manager. Tested with jack2 and 'jack_load netmanager'.
The driver will receive and send data (no midi yet) from and to the
manager in sync with the manager, without resampling and with a fixed
latency.
