Description

The zbus proxy agent IPC backend in subsys/zbus/proxy_agent/zbus_proxy_agent_ipc.c logged the channel name of a rejected inter-domain frame with a plain %s conversion. The frame type struct zbus_proxy_msg carries a fixed-size channel_name[] array as its last member, and nothing in the transport guarantees the array is NUL-terminated. The only code that verifies termination is zbus_proxy_agent_receive_cb() in subsys/zbus/proxy_agent/zbus_proxy_agent.c, which rejects the frame in precisely those cases — so the warning printed a non-terminated buffer exactly on the error paths where the name had been found invalid (or, for an invalid message_size, had not been inspected at all). Any peer domain able to place a frame of sizeof(struct zbus_proxy_msg) bytes on the bound ipc_service endpoint can trigger it, by sending a frame with an out-of-range message_size or with channel_name[] containing no NUL byte. Reaching the code requires CONFIG_ZBUS_PROXY_AGENT_IPC and logging built at warning level or above (the default), and requires control over the firmware of the peer domain — typically a second core on the same SoC. The resulting strlen() inside the log packager walks past the end of the frame object until it finds a zero byte. With the icmsg backend the frame lives in a stack buffer of the IPC work-queue thread, so bytes of that thread's stack are rendered into the log message; with the rpmsg backends the scan continues through the shared vring memory. Impact is bounded to disclosure of a small amount of adjacent memory into the receiving domain's log sink, plus a possible fatal fault if the scan leaves a mapped region; the log packager's own -ENOSPC bound prevents the overrun from becoming a write. The fix bounds the conversion with %.*s and MIN(msg->channel_name_len, sizeof(msg->channel_name)).

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.4",
  "pubDate": "2026-10-11T18:16:58.113Z",
  "pubdate": "2026-10-11T18:16:58.113Z",
  "executiveSummary": "This vulnerability is an out-of-bounds (OOB) memory read within the zbus proxy agent IPC backend, classified as an Improper Null Termination vulnerability.\nThe issue arises because the application processes a fixed-size character array, channel_name[], without ensuring it is null-terminated before passing it to a logger function using a plain %s conversion specifier.\nAn attacker with control over a peer domain, such as a secondary SoC core, can transmit a malformed IPC frame of size struct zbus_proxy_msg that lacks a null terminator or specifies an invalid message_size.\nUpon receiving such a frame, the logging subsystem performs a strlen() operation on the non-terminated buffer, causing it to read past the intended memory boundary. This results in the leakage of sensitive data residing on the IPC thread's stack or within shared vring memory into the system logs.\nThe vulnerability is exploitable when CONFIG_ZBUS_PROXY_AGENT_IPC is enabled and logging is set to warning level or higher. While the log packager's internal buffer limit prevents arbitrary memory corruption or code execution, the impact includes unauthorized information disclosure and potential system crashes due to memory access violations if the read scan reaches unmapped memory regions.",
  "technicalDetails": "The root cause of the vulnerability is located in subsys/zbus/proxy_agent/zbus_proxy_agent_ipc.c, where the zbus proxy agent handles incoming IPC frames. The structure zbus_proxy_msg defines channel_name[] as a fixed-size array without a guaranteed null terminator.\nThe vulnerability is triggered during the error-handling path in zbus_proxy_agent_receive_cb() (located in subsys/zbus/proxy_agent/zbus_proxy_agent.c). When an IPC frame is received that is deemed invalid—either due to an out-of-range message_size or an improperly terminated channel_name[] array—the system attempts to log the channel name using a format string with a %s conversion specifier.\nBecause %s expects a null-terminated string, the log formatter invokes strlen() on the fixed-size buffer. Since no null byte is present, strlen() continues reading contiguous memory until it encounters an arbitrary 0x00 byte. This behavior leads to the leakage of adjacent memory contents.\nThe execution flow involves the following: 1. The attacker crafts a malicious struct zbus_proxy_msg frame targeting the ipc_service endpoint. 2. The frame is placed on the endpoint, triggering the callback in the receiving domain. 3. The validation logic fails, routing the execution to the logging statement. 4. The log packager reads beyond the legitimate bounds of the channel_name[] array. 5. If the backend is icmsg, the logger accesses the IPC work-queue thread stack; if using an rpmsg backend, it scans the shared vring memory. 6. The leaked memory bytes are then written to the system's log sink.\nThe impact of this disclosure is limited to the volume of adjacent memory exposed to the logging sink before the log packager reaches its -ENOSPC limit. A potential for a denial-of-service (DoS) condition exists if the memory scan traverses into unmapped or protected memory regions, resulting in a fatal hardware exception or kernel panic. The exploitation requires the attacker to have the ability to execute code on a peer domain capable of communicating over the IPC interface, typically a secondary core on the same SoC."
}