CVE-2026-8718

This is a kernel-heap overflow in Zephyr's syscall layer, but the vulnerability's root cause is more subtle than a typical buffer overflow. The getsockopt handler for DTLS Connection IDs uses a bounce buffer sized exactly to the user-supplied optlen parameter, then passes that buffer to mbedtls_ssl_get_peer_cid() — a function that writes up to 32 bytes with no size parameter. When optlen is less than 32, overflow is architecturally guaranteed regardless of what mbedtls actually returns. The bounce buffer, intended to protect the kernel from user-supplied buffers, creates precisely the condition it was designed to prevent: a kernel-heap allocation sized by userspace metadata that receives data from a subsystem with fixed output requirements. The patch correctly validates optlen >= MBEDTLS_SSL_CID_OUT_LEN_MAX before allocation, but this fixes a parameter validation issue that only exists because the syscall boundary model is structurally incompatible with the mbedtls API contract. The severity (CVSS 8.4) is driven by the kernel-heap write, but the overflow content is the remote peer's negotiated CID — data the caller already received during the TLS handshake, making information disclosure minimal. The real risk is heap metadata corruption from attacker-controllable CID bytes landing in adjacent kernel objects. If you run Zephyr with CONFIG_USERSPACE enabled and handle DTLS CID, you need the v3.5.x or later patch. Check that your getsockopt callers always provide at least 32-byte buffers, and audit other syscall paths that pass user-sized buffers to fixed-output mbedtls or similar APIs — the bounce buffer model creates this mismatch wherever user length metadata drives kernel allocation decisions.

Reviewed through automated stages and approved by a human before publication.