Description

The UMP Stream responder library in lib/midi2/ump_stream_responder.c builds reply packets in a 16-byte struct midi_ump (uint32_t data[4]). The builders make_endpoint_info() and make_function_block_info() 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 midi_ump 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 (UMP_MT_UMP_STREAM), 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 ump_stream_respond(). 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 midi_ump res = {0};), so the trailing words are cleared before transmission. These are the only two responder builders that left trailing words unset (send_string() already zeroes its buffer), so the leak is fully closed.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-24T16:16:55.530Z",
  "pubdate": "2026-08-24T16:16:55.530Z",
  "executiveSummary": "An information disclosure vulnerability exists in the UMP Stream responder library, specifically within the file lib/midi2/ump_stream_responder.c. The vulnerability is classified as a use of uninitialized variable (CWE-457/CWE-908).\nThe flaw impacts systems utilizing the UMP Stream responder library, including the in-tree Network MIDI 2.0 server (subsys/net/lib/midi2/netmidi2.c) handling UDP datagrams and implementations serving USB MIDI 2.0 hosts.\nThe security impact is strictly limited to confidentiality, allowing an unauthenticated remote peer to extract sensitive residual data from the device's stack memory. There is no memory-corruption, integrity, or availability impact.\nAttacker capabilities are restricted to reading stack contents through repeatedly triggered discovery requests. Exploitation requires the ability to send attacker-supplied UMP Stream Endpoint-Discovery or Function-Block-Discovery requests to the responder. In default configurations of the Network MIDI 2.0 server, sessions can be established without authentication, facilitating remote exploitation.",
  "technicalDetails": "The root cause of the vulnerability is the use of uninitialized local variables within the packet building functions make_endpoint_info() and make_function_block_info() inside lib/midi2/ump_stream_responder.c.\nThe vulnerable component constructs reply packets utilizing a 16-byte struct midi_ump containing uint32_t data[4]. The functions make_endpoint_info() and make_function_block_info() declare the result struct without initialization (struct midi_ump res;) and populate only the first two words (res.data[0] and res.data[1]). Consequently, the remaining two words (res.data[2] and res.data[3]) retain stale stack contents.\nBecause Endpoint Info and Function Block Info notifications are UMP Stream messages of type UMP_MT_UMP_STREAM with a length of 4 words, the entire 16-byte packet—including the two uninitialized words containing residual stack data—is transmitted verbatim by the cfg->send() function.\nThe attack flow proceeds as follows: 1) An attacker initiates a session with the responder by sending malicious or standard UMP Stream Endpoint-Discovery or Function-Block-Discovery requests via ump_stream_respond(). In the Network MIDI 2.0 server (subsys/net/lib/midi2/netmidi2.c), these requests arrive as UDP datagrams over the network without requiring authentication under default configurations. 2) Upon receiving the discovery request, the vulnerable device invokes the uninitialized response builders. 3) The responder generates a 4-word UMP Stream message incorporating 8 bytes of uninitialized stack memory into the trailing words of the packet. 4) The device transmits the packet back to the peer via cfg->send(). 5) The attacker receives the response containing the leaked stack memory, which may include residual data or sensitive pointer values. Because the request is freely repeatable, the attacker can repeatedly poll the device to harvest additional stack memory."
}