Blog post · October 26, 2026 · kb.cert.org
VU#128947: COVESA vsomeip 3.7.4 fixes memory allocation flaw in TCP endpoints
- About VU
- Read the original
Summary
COVESA's open source vsomeip, an implementation of the SOME/IP automotive communication middleware, contains a memory allocation vulnerability that lets a remote, unauthenticated peer exhaust host memory and cause denial of service.
vsomeip implements Scalable service-Oriented MiddlewarE over IP, which is widely used for communication between electronic control units in automotive and other embedded environments. Each SOME/IP message starts with a 16-byte header containing a 32-bit length field declaring the size of the message that follows. The flaw, tracked as CVE-2026-91141 and present in versions 3.7.3 and below, lies in reliable TCP endpoints: vsomeip grows the receive buffer to the declared length before confirming those bytes have actually arrived.
In the default configuration no size limit applies to reliable endpoints, so a peer can declare a message of up to roughly 4 GB and cause the receiver to allocate that memory. A freshly accepted connection reaches this allocation on its first message, so no valid service, credentials, or SOME/IP authentication is required. The client endpoint behaves the same way, so a malicious or compromised server can attack a connecting client. Deployments that explicitly configure a reliable message-size limit are not affected.
An unauthenticated remote peer can force a host to allocate attacker-chosen memory, up to about 4 GB per connection, by sending one short message over TCP to any reachable reliable SOME/IP endpoint in the default configuration. On a memory-constrained node, a service limited to 1.5 GB was OOM-killed by a single 16-byte message claiming a 3 GB payload. On a memory-rich host, each allocation is released when its connection closes, so sustained exhaustion and denial of service follow from holding or repeating connections.
Upgrading to vsomeip 3.7.4, released 2026-07-06, resolves the issue. The fix replaces the unlimited compile-time default MESSAGE_SIZE_UNLIMITED with a bounded DEFAULT_MAX_MESSAGE_SIZE of 10 MiB, so reliable endpoints reject oversized declared lengths before growing the receive buffer even without an explicit limit. The release also adds a regression test for an oversized length field. The issue is publicly known and tracked as COVESA/vsomeip issue #1009, opened 2026-02-26.
Deployments unable to upgrade immediately can set max-payload-size-reliable, or the equivalent per-service reliable message-size limit, which the advisory describes as the most effective mitigation without upgrading. Exposure should be minimized through network segmentation, with reliable endpoints confined to trusted, isolated in-vehicle or lab networks and firewall or access-control rules limiting connectivity to known, authorized peers. SOME/IP endpoints should never be exposed to untrusted or external networks. Operators should watch for anomalous memory growth and unexpected or repeated inbound TCP connections to SOME/IP ports.
Our summary. The original keeps its own byline.