CVE-2026-18418Low· 3.4▾ SunlitThe 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_nam…
▾ Sunlit zone — Low / medium · no exploitation signal
impact 18.7 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake.
Exploit-prediction probability, daily snapshots since Oct 13.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
0.1%
Last analysed / modified upstream
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)).
Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-18748Low· 3.5Out-of-bounds read in Bluetooth Classic A2DP codec information element handling
CVE-2026-10680High· 7.6Out-of-bounds access in Zephyr BR/EDR L2CAP configuration request handling via `uint16_t` length underflow
CVE-2026-10672High· 8.2Unterminated URI buffer causes out-of-bounds read in LwM2M firmware pull (Package URI)
CVE-2026-10673High· 8.3Out-of-bounds write in ADIN2111/ADIN1110 OA SPI Ethernet RX frame reassembly
CVE-2026-10657Low· 3.7Out-of-bounds read in Zephyr DNS resolver mDNS suffix check (memcmp past string NUL)
CVE-2026-75085Medium· 4.2The STM32WBA IEEE 802.15.4 driver in drivers/ieee802154/ieee802154_stm32wba.c computed the packet length of a received frame as pkt_len = rx_frame->length - IEEE802154_FCS_LENGTH without first checking that the radio-reported length coul…