Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.0",
  "pubDate": "2026-09-21T17:17:34.207Z",
  "pubdate": "2026-09-21T17:17:34.207Z",
  "executiveSummary": "The Intel SEDI IPM driver suffers from a critical buffer overflow vulnerability originating from insufficient bounds checking during inbound message processing.\nThe flaw exists within the ipm_event_dispose() function, where the driver reads a length field from a peer-controlled doorbell register and uses it to perform a memory copy into a fixed-size buffer without verifying the input size.\nAn attacker with driver-level or raw BAR access on the host CPU can exploit this by crafting a malicious payload length, triggering an out-of-bounds memory write.\nThe impact includes arbitrary kernel data structure corruption and system crashes, as the overflow overwrites adjacent .bss memory, including critical synchronization primitives such as k_sem and k_mutex.\nExploitation requires an application to have registered an IPM receive callback via ipm_register_callback().\nGiven the ability to corrupt kernel memory from the host, this vulnerability poses a significant risk to the integrity and availability of the affected device.",
  "technicalDetails": "The root cause of the vulnerability is an unbounded memory copy operation within the drivers/ipm/ipm_sedi.c file, specifically inside the ipm_event_dispose() function. When an inbound message interrupt is received, the driver utilizes the IPC_HEADER_GET_LENGTH() macro to extract a payload length from the peer-written doorbell register. This value, which can be as large as 1023 bytes (10-bit width), is passed directly to the sedi_ipc_read_msg() function to populate the incoming_data_buf buffer within the struct ipm_sedi_context structure.\nThe target buffer, incoming_data_buf, is strictly defined with a maximum capacity of 128 bytes (IPC_DATA_LEN_MAX). Because the underlying HAL implementation of sedi_ipc_read_msg() relies on a DBG_CHECK for bounds validation, this safety measure is removed during production builds, leaving the driver exposed to memory corruption. The attacker can program the doorbell register to indicate a length up to 1023 bytes, forcing the driver to write past the allocated buffer bounds.\nThe attack flow begins with the peer processor, such as the host CPU's ISH driver, interacting with the memory-mapped register window. By manipulating the doorbell register, the attacker triggers the interrupt handler to execute the overflow. The subsequent memory corruption targets the .bss segment. Because the incoming_data_buf is adjacent to critical kernel structures—notably the k_sem and k_mutex objects used for transmit path synchronization—the overflow overwrites these structures. These structures contain self-referential list pointers, and their corruption leads to immediate kernel instability or a complete system crash.\nPost-exploitation, the attacker leverages the ability to read bytes from registers immediately following the message window, which are themselves peer-programmable, to further control the overflow data. The combination of the overflow and the ability to influence the injected data provides an attacker with a primitive for kernel data-structure corruption. As this occurs within an interrupt context, the exploit is immediate and high-impact, effectively bypassing typical user-space memory protections by operating directly within the kernel address space of the firmware or integrated system."
}