CVE-2026-18418: Out-of-bounds read when the zbus proxy agent IPC backend logs a rejected peer frame's channel name

The zbus proxy agent IPC backend in subsys/zbus/proxyagent/zbusproxyagentipc.c logged the channel name of a rejected inter-domain frame with a plain %s conversion. The frame type struct zbusproxymsg carries a fixed-size channelname[] array as its last member, and nothing in the transport guarantees the array is NUL-terminated. The only code that verifies termination is zbusproxyagentreceivecb() in subsys/zbus/proxyagent/zbusproxyagent.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 messagesize, had not been inspected at all).

Any peer domain able to place a frame of sizeof(struct zbusproxymsg) bytes on the bound ipcservice endpoint can trigger it, by sending a frame with an out-of-range messagesize or with channelname[] containing no NUL byte. Reaching the code requires CONFIGZBUSPROXYAGENTIPC 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->channelnamelen, sizeof(msg->channelname)).