Description
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.
Published: 2026-10-19
Score: 8.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Remote Code Execution
Action: Patch
AI Analysis

Impact

The vulnerability arises from an unbounded memcpy in the OSDP Control Panel reply parser, allowing an attacker who can inject frames on the RS‑485 bus to write beyond the fixed‑size event structure. This overflow can corrupt the stack, causing a crash or potentially hijacking the return address of the OSDP receive thread. The flaw is a classic out‑of‑bounds write (CWE‑787) that enables remote code execution against the access‑control panel if the attacker can send crafted frames.

Affected Systems

The issue exists in Zephyr RTOS, specifically the OSDP subsystem in zephyrproject:zephyr. It affects builds that enable CONFIG_OSDP with CONFIG_OSDP_MODE_CP and register an application event callback. Versions prior to the commit that added bounds checks for REPLY_KEYPPAD and REPLY_RAW are vulnerable; no specific release numbers are listed in the advisory.

Risk and Exploitability

The CVSS score of 8.8 reflects a high severity, and the EPSS score is not available, indicating limited data on exploitation frequency. The vulnerability is not listed in CISA’s KEV catalog. Exploitation requires physical or network access to the RS‑485 bus and the ability to send a valid frame with a correct length and CRC, but no matching of reply ID to command is enforced. An attacker can thus send a forged REPLY_KEYPPAD or REPLY_RAW frame with an oversized payload, triggering the overflow. The risk is elevated for systems where the RS‑485 bus is exposed to untrusted devices or where OSDP is used in public or semi‑public access‑control environments.

Generated by OpenCVE AI on October 20, 2026 at 11:34 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the Zephyr RTOS update that implements bounds checking in the OSDP reply parser (the commit referenced in the advisory).
  • Disable or limit the OSDP Control Panel functionality if not required, or isolate the RS‑485 bus to only trusted peripherals.
  • Enable Zephyr stack integrity features such as stack canaries, and configure the secure channel (CONFIG_OSDP_SC_ENABLED) to reject unauthenticated frames.

Generated by OpenCVE AI on October 20, 2026 at 11:34 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Tue, 20 Oct 2026 19:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'total'}, 'version': '2.0.3'}

Mon, 19 Oct 2026 21:45:00 +0000

Type Values Removed Values Added
First Time appeared Zephyrproject
Zephyrproject zephyr
Vendors & Products Zephyrproject
Zephyrproject zephyr

Mon, 19 Oct 2026 20:45:00 +0000

Type Values Removed Values Added
Description 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.
Title Stack out-of-bounds write in the OSDP Control Panel reply parser
Weaknesses CWE-787
References
Metrics cvssV3_1

{'score': 8.8, 'vector': 'CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}

Subscriptions

Zephyrproject Zephyr
cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-11-04T05:01:12.497Z

Reserved: 2026-08-19T17:53:26.698Z

Link: CVE-2026-76788

cve-icon Vulnrichment

Updated: 2026-10-20T18:07:49.192Z

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-10-19T21:18:01.380

Modified: 2026-11-04T05:19:01.180

Link: CVE-2026-76788

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-20T11:45:14Z

Weaknesses