GHSA-78p3-4gv3-qjh9: Out-of-bounds write in the Intel SEDI IPM driver from an unvalidated inbound doorbell length

The Intel SEDI IPM (inter-processor mailbox) driver in drivers/ipm/ipmsedi.c handles an inbound message interrupt in ipmeventdispose(). It read the peer-written doorbell register, extracted the payload length with IPCHEADERGETLENGTH(), and passed that length straight to sediipcreadmsg() to copy the message into struct ipmsedicontext.incomingdatabuf, without checking it against the buffer size. The doorbell length field is 10 bits wide (IPCHEADERLENGTHMASK is 0x03FF), so it can encode up to 1023 bytes, while incomingdatabuf is IPCDATALENMAX (128) bytes. The bounds check in the underlying HAL sediipcreadmsg() is a DBGCHECK that compiles away unless CONFIGDEBUG 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 intelish5 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 ipmregistercallback(), 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 ipmsedicontext — including the ksem and kmutex 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 IPCDATALENMAX, logging it and acknowledging the doorbell so the peer is not left waiting.