ZephyrProject Zephyr up to 4.4.1 IPM Driver drivers/ipm/ipm_sedi.c ipm_event_dispose out-of-bounds write

Summaryinfo

A vulnerability classified as very critical has been found in ZephyrProject Zephyr up to 4.4.1. This vulnerability affects the function ipm_event_dispose of the file drivers/ipm/ipm_sedi.c of the component IPM Driver. This manipulation causes out-of-bounds write. The identification of this vulnerability is CVE-2026-17051. The attack can only be executed locally. There is no exploit available. It is recommended to upgrade the affected component.

Detailsinfo

A vulnerability classified as very critical was found in ZephyrProject Zephyr up to 4.4.1. Affected by this vulnerability is the function ipm_event_dispose of the file drivers/ipm/ipm_sedi.c of the component IPM Driver. The manipulation with an unknown input leads to a out-of-bounds write vulnerability. The CWE definition for the vulnerability is CWE-787. The product writes data past the end, or before the beginning, of the intended buffer. As an impact it is known to affect confidentiality, integrity, and availability. The summary by CVE is:

The Intel SEDI IPM (inter-processor mailbox) driver in drivers/ipm/ipm_sedi.c handles an inbound message interrupt in ipm_event_dispose(). It read the peer-written doorbell register, extracted the payload length with IPC_HEADER_GET_LENGTH(), and passed that length straight to sedi_ipc_read_msg() to copy the message into struct ipm_sedi_context.incoming_data_buf, without checking it against the buffer size. The doorbell length field is 10 bits wide (IPC_HEADER_LENGTH_MASK is 0x03FF), so it can encode up to 1023 bytes, while incoming_data_buf is IPC_DATA_LEN_MAX (128) bytes. The bounds check in the underlying HAL sedi_ipc_read_msg() is a DBG_CHECK that compiles away unless CONFIG_DEBUG is set, so no check remained in a production image. The doorbell register is written by the peer processor on the other side of the IPC link — for the intel_ish_5_* targets, the host CPU's ISH driver, reached through the device's memory-mapped register window. Host-side software with driver-level or raw BAR access can therefore set a length of up to 1023 and cause the interrupt handler to copy far past the destination buffer. The affected path requires an application to have registered an IPM receive callback via ipm_register_callback(), which is the driver's normal mode of use. The result is an out-of-bounds write of up to 895 bytes into static (.bss) memory, performed in interrupt context. The overflow first clobbers the rest of struct ipm_sedi_context — including the k_sem and k_mutex used by the transmit path, whose wait queues contain self-referential list pointers — and then adjacent static data, giving a kernel data-structure corruption and crash primitive. The overflowing bytes are read from registers following the message window, a portion of which are themselves peer-programmable. The fix rejects any doorbell whose encoded length exceeds IPC_DATA_LEN_MAX, logging it and acknowledging the doorbell so the peer is not left waiting.

The advisory is shared at github.com. This vulnerability is known as CVE-2026-17051 since 07/24/2026. The exploitation appears to be easy. An attack has to be approached locally. Additional levels of successful authentication are needed for exploitation. Technical details are known, but no exploit is available. The price for an exploit might be around USD $0-$5k at the moment (estimation calculated on 09/21/2026).

Upgrading to version 4.4.2 eliminates this vulnerability. Applying the patch 74c7d27925055e8c3c8aef7a9f16cae6a8c64b70 is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Type

• Project Management Software

Vendor

• ZephyrProject

Name

• Zephyr

Version

• 4.4.0
• 4.4.1

CPE 2.3info

• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion