CVE-2026-76788

The OSDP Control Panel reply parser cp decode response() in subsys/mgmt/osdp/src/osdp cp.c decodes replies from a Peripheral Device into a stack-allocated struct osdp event. For the REPLY KEYPPAD and REPLY RAW reply types, the payload length is taken from the received frame and the only validation performed is that the declared length is self-consistent with the number of payload bytes present in the frame. Because the attacker controls both the length field and the frame length, that check imposes no bound, and the subsequent memcpy() writes into the fixed 64-byte data arrays of struct osdp event keypress / struct osdp event cardread (OSDP EVENT MAX DATALEN). The sibling REPLY FMT handler in the same switch already carried the missing > OSDP EVENT MAX DATALEN bound.

The defect is reached from cp process reply(), which reads bytes from the OSDP RS-485 channel and passes them through osdp phy check packet() and osdp phy decode packet() before dispatching on the reply ID. Triggering it requires CONFIG OSDP with CONFIG OSDP MODE CP and an application event callback registered (the normal Control Panel integration), plus a frame carrying a correct SOM, a valid CRC-16, and a matching 2-bit sequence number — all of which are computable or observable by anyone on the bus. No check ties the reply ID to the outstanding command, so an oversized REPLY KEYPPAD or REPLY RAW is accepted as the answer to a routine CMD POLL. A malicious or compromised card reader, or anyone with access to the RS-485 wiring, can supply such a frame; CONFIG OSDP SC ENABLED only helps while a secure channel is active, and a single unauthenticated frame carrying a bad MAC causes sc deactivate(), after which plaintext replies are again accepted.

With the default CONFIG OSDP UART BUFFER LENGTH of 256, roughly 180 bytes of fully attacker-chosen data can be written past the end of the stack-allocated event object, over saved registers and the return address on typical Cortex-M and RISC-V frame layouts (Zephyr does not enable stack canaries by default). The impact ranges from a hard crash of the access-control panel to potential control-flow hijack in the context of the OSDP receive thread. The fix adds an OSDP EVENT MAX DATALEN bound to both handlers, capping each memcpy() at the size of its destination.