CVE-2026-13343: Uninitialised stack memory disclosure in the MIDI 2.0 UMP Stream responder
The UMP Stream responder library in lib/midi2/umpstreamresponder.c builds reply packets in a 16-byte struct midiump (uint32t data[4]). The builders makeendpointinfo() and makefunctionblockinfo() populate only the first two words (res.data[0] and res.data[1]) and, before this fix, declared their result as an uninitialised local (struct midiump res;). The remaining two words (res.data[2], res.data[3]) retain stale stack contents.
Endpoint Info and Function Block Info notifications are UMP Stream messages (UMPMTUMPSTREAM), which are 4 words long, so the full 16-byte packet — including the two uninitialised words — is transmitted verbatim by cfg->send(). The responder is driven by attacker-supplied UMP Stream Endpoint-Discovery / Function-Block-Discovery requests via umpstreamrespond(). In the in-tree Network MIDI 2.0 server (subsys/net/lib/midi2/netmidi2.c) these requests arrive as UDP datagrams and, with the default no-authentication endpoint, a remote peer can establish a session and trigger the responses; the same library also serves USB MIDI 2.0 hosts.
Each discovery request causes the device to disclose 8 bytes of its own uninitialised stack memory to the peer, and the request is freely repeatable. This is a confidentiality-only information leak (root cause is use of an uninitialised variable, CWE-457/CWE-908); the leaked words could include residual data or pointer values. There is no memory-corruption, integrity, or availability impact.
The fix zero-initialises both result structs (struct midiump res = {0};), so the trailing words are cleared before transmission. These are the only two responder builders that left trailing words unset (sendstring() already zeroes its buffer), so the leak is fully closed.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Ensure UDP Endpoint-Discovery / Function-Block-Discovery UMP Stream requests cannot be triggered by a remote peer on the default no-authentication endpoint; require authentication or otherwise restrict session establishment so the attacker-supplied requests cannot be used to elicit responses.
in-tree Network MIDI 2.0 server (subsys/net/lib/midi2/netmidi2.c) default no-authentication endpoint = authenticated (restrict remote session establishment) - Configuration
Update the responder builders make_endpoint_info() and make_function_block_info() to zero-initialize the local result struct (use `struct midi_ump res = {0};`) so that all four UMP Stream words are cleared before reply transmission; this prevents leakage of trailing uninitialised stack words (res.data[2] and res.data[3]).
UMP Stream responder library (lib/midi2/ump_stream_responder.c) make_endpoint_info() / make_function_block_info() local result initialization = struct midi_ump res = {0};
Event History
Frequently Asked Questions
Which deployments are exposed to remote exploitation?
The in-tree Network MIDI 2.0 server is remotely exposed when using its default no-authentication endpoint. A remote peer can establish a session over UDP and send discovery requests that trigger the affected replies.
What does an attacker need to do to obtain leaked data?
An attacker needs to send UMP Stream Endpoint-Discovery or Function-Block-Discovery requests to the responder. Each such request causes a response containing 8 bytes of uninitialised stack memory.
Are USB MIDI 2.0 devices also affected?
The same responder library also serves USB MIDI 2.0 hosts. The available information identifies USB MIDI 2.0 hosts as another interface using the affected library, but does not specify additional access requirements.