Fast DDS is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group ). ParticipantGenericMessage is the DDS Security control-message container that carries not only the handshake but also on going security-control traffic after the handshake, such as crypto-token exchange, rekeying, re-authentication, and token delivery for newly appearing endpoints. On receive, the CDR parser is invoked first and deserializes the `message_data` (i .e., the `DataHolderSeq`) via the `readParticipantGenericMessage → readDataHolderSeq` path. The `DataHolderSeq` is parsed sequentially: a sequence count (`uint32`), and for each DataHolder the `class_id` string (e.g. `DDS:Auth:PKI-DH:1.0+Req`), string properties (a sequence of key/value pairs), and binary properties (a name plus an octet-vector). The parser operat es at a stateless level and does not know higher-layer state (for example, whether the handshake has already completed), s o it fully unfolds the structure before distinguishing legitimate from malformed traffic. Because RTPS permits duplicates, delays, and retransmissions, a receiver must perform at least minimal structural parsing to check identity and sequence n umbers before discarding or processing a message; the current implementation, however, does not "peek" only at a minimal header and instead parses the entire `DataHolderSeq`. As a result, prior to versions 3.4.1, 3.3.1, and 2.6.11, this parsi ng behavior can trigger an out-…

Affected: Ubuntu:Pro:22.04:LTS: fastdds, Ubuntu:24.04:LTS: fastdds, Ubuntu:25.10: fastdds, Ubuntu:26.04:LTS: fastdds

Fast DDS is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group ). ParticipantGenericMessage is the DDS Security control-message container that carries not only the handshake but also on going security-control traffic after the handshake, such as crypto-token exchange, rekeying, re-authentication, and token delivery for newly appearing endpoints. On receive, the CDR parser is invoked first and deserializes the `message_data` (i .e., the `DataHolderSeq`) via the `readParticipantGenericMessage → readDataHolderSeq` path. The `DataHolderSeq` is parsed sequentially: a sequence count (`uint32`), and for each DataHolder the `class_id` string (e.g. `DDS:Auth:PKI-DH:1.0+Req`), string properties (a sequence of key/value pairs), and binary properties (a name plus an octet-vector). The parser operat es at a stateless level and does not know higher-layer state (for example, whether the handshake has already completed), s o it fully unfolds the structure before distinguishing legitimate from malformed traffic. Because RTPS permits duplicates, delays, and retransmissions, a receiver must perform at least minimal structural parsing to check identity and sequence n umbers before discarding or processing a message; the current implementation, however, does not "peek" only at a minimal header and instead parses the entire `DataHolderSeq`. As a result, prior to versions 3.4.1, 3.3.1, and 2.6.11, this parsi ng behavior can trigger an out-of…