COVESA vsomeip TCP Buffer Lets Remote Peers Exhaust Memory

A service limited to 1.5 GB of memory was killed after its COVESA vsomeip TCP endpoint received a 16-byte message declaring a 3 GB payload. CERT/CC reports that versions 3.7.3 and earlier can allocate the declared size before the rest of a SOME/IP message arrives. A remote peer with a TCP path to a reliable endpoint can exhaust the host memory without credentials or a valid service request. The client endpoint is exposed too when it connects to a malicious or compromised server.

For teams running vsomeip on vehicle ECUs, embedded systems or lab networks, check which reliable TCP endpoints other hosts can reach as well as their installed versions. Release 3.7.4 fixes CVE-2026-91141. Until an upgrade is deployed, an explicitly configured reliable message-size limit can block the oversized declaration.

A length field drives allocation

SOME/IP messages start with a 16-byte header containing a 32-bit length field. On a reliable TCP endpoint, the older vsomeip receive path grows its buffer to the size in that field before checking how many bytes have actually arrived. Its default configuration puts no size limit on reliable messages. That lets a newly accepted connection reach the allocation path on its first message; the peer needs only network access to the endpoint.

The declared length can approach 4 GB per connection. CERT/CC describes the 1.5 GB service limit and 3 GB declaration as an out-of-memory kill from one short message. On a larger host, memory allocated to a single connection is released when that connection closes. Holding or repeating connections can keep the pressure on memory. Count TCP sessions and watch the process resident memory alongside the host or container memory limit rather than assuming every large allocation ends in an immediate crash.

The same handling applies to vsomeip clients receiving data from a server. Trace both the services accepting TCP connections and the clients connecting to servers when inventorying exposure; prioritize those reliable TCP paths in the CERT/CC note.

Fixed defaults and configured limits

CERT/CC says the 3.7.4 fix changes the compile-time default from MESSAGE_SIZE_UNLIMITED to DEFAULT_MAX_MESSAGE_SIZE of 10 MiB. Reliable endpoints reject an oversized declared length before expanding the receive buffer under that default. The release includes an oversized-length regression test. CERT/CC credits Jaafer Rahmani with reporting the issue and records its public issue as COVESA/vsomeip #1009; its vendor listing is marked Unknown and says it has received no vendor statement.

A service can legitimately need a message larger than 10 MiB. Size its reliable limit to the service traffic and verify that the chosen setting rejects lengths above that limit. CERT/CC is explicit about the mitigating case: “Deployments that explicitly configure a reliable message-size limit are not affected.” That applies to the vulnerable allocation behavior described here, while the selected limit still has to fit actual application messages.

Check endpoints and bound messages

Inventory installed vsomeip versions and the configured max-payload-size-reliable value, including equivalent per-service reliable limits. Upgrade affected instances to 3.7.4 or later. For instances awaiting an upgrade, set a service-appropriate reliable limit instead of leaving the unlimited default. Verify the running process uses the updated version or limit and that its reliable endpoint rejects a declared length above the configured bound before memory grows; use a safe, isolated validation harness rather than testing against a live vehicle.

Restrict TCP reachability to known peers on trusted in-vehicle or lab segments. Include client connections to servers in that access review. Watch process memory and out-of-memory events alongside unexpected or repeated inbound TCP connections to the relevant SOME/IP ports. Those observations help triage a stressed service, while version and configuration checks establish whether the vulnerable buffer path remains available.

The fix puts the memory decision after a size check. Keep the connection path narrow and confirm the bound in the process that handles traffic, because a configuration file sitting beside a running ECU is only useful when that process has loaded it.