14.4. What’s Fixed in 7.3.1

This section describes bugs fixed in Routing Service 7.3.1. These are fixes since 7.3.0.

Connext 7.3.1 is a maintenance release in the 7.3 long-term support (LTS) series. See Previous Releases for all other fixes in 7.3 LTS. See the Connext Versions and Lifecycle page for more information on RTI’s software release model.

For what’s new and fixed in other products in the Connext suite, see those products’ release notes on the RTI Community Portal or in your installation.

[Critical]: System-stopping issue, such as a crash or data loss.
[Major]: Significant issue with no easy workaround.
[Minor]: Issue that usually has a workaround.
[Trivial]: Small issue, such as a typo in a log.

14.4.1. Serialization and Deserialization

14.4.1.1. [Critical] Unexpected error messages when Routing Service disposed of an instance while using batching and setting serialize_key_with_dispose to TRUE *

Consider the following Routing Service writer QoS:

<datawriter_qos>
                <batch>
                    <enable>true</enable>
                </batch>
                <protocol>
                    <serialize_key_with_dispose>true</serialize_key_with_dispose>
                </protocol>
            </datawriter_qos>

The data type is keyed, and the serialized key is not aligned to a 4-byte boundary.

Imagine that Routing Service successfully sends one batch with a data sample of a given instance and then attempts to send another batch whose first sample is a dispose message for that same instance.

When using release libraries, Routing Service would have successfully sent the second batch, but the DataReader that was reading the batch from Routing Service would have experienced this error:

ERROR MIGInterpreter_parse:submessage not aligned to 4

When using debug libraries, Routing Service would have failed to send the batch and generated this error:

mig.2.0/srcC/generator/Generator.c:1216:RTI0x200003a:!precondition: "!(sample != ((void *)0) && (((sample)->serializedData[encapsulationIndex].serializedData.pointer == ((void *)0) || ((sample)->serializedData[encapsulationIndex].serializedData.length & 0x3) == 0)) && (((sample)->protocolParameters.pointer == ((void *)0) || ((sample)->protocolParameters.length & 0x3) == 0)))

This problem only affected 7.3.0 and above. Routing Service now successfully sends the batch, and the DataReader successfully receives the batch when using either release or debug libraries.

[RTI Issue ID ROUTING-1288]

14.4.1.2. [Critical] Error propagating samples received using Zero Copy in a route setting <content_filter> or enabling <filter_propagation>

A route setting <content_filter> or enabling <filter_propagation> may have failed to propagate samples when the samples were received from a DataWriter using Zero Copy transfer over shared memory.

When this problem occurred, Routing Service generated the following errors:

ERROR [0x0101BE35,0x47B28D9B,0x87A311F6:0x80000004{Entity=DR,MessageKind=DATA}|RECEIVE FROM 0x0101D676,0xE92E1D8E,0x91728D11:0x80000003] DDS_DynamicData2TypePlugin_serialize:error copying CDR buffer (batching is not supported)
ERROR [0x0101BE35,0x47B28D9B,0x87A311F6:0x80000004{Entity=DR,MessageKind=DATA}|RECEIVE FROM 0x0101D676,0xE92E1D8E,0x91728D11:0x80000003] PRESPsReaderQueue_evaluateSample:serialize failed
ERROR [0x0101BE35,0x47B28D9B,0x87A311F6:0x80000004{Entity=DR,MessageKind=DATA}|RECEIVE FROM 0x0101D676,0xE92E1D8E,0x91728D11:0x80000003] PRESPsReaderQueue_addQueueEntryToPolled:The sample couldn't be evaluated

This issue only occurred when the DataWriter sending the samples did not use writer-side filtering.

[RTI Issue ID ROUTING-1189]

14.4.2. TopicQueries

14.4.2.1. [Critical] Snapshot TopicQuery responses may have been marked as complete

In release 6.1.2.16, Connext introduced a new flag in SampleInfo called DDS_INCOMPLETE_SNAPSHOT_TOPIC_QUERY. This flag can be set by a DataReader on the last sample of a TopicQuery response to allow the application to detect incomplete snapshots and potentially reissue the TopicQuery.

However, when using proxied TopicQueries and having multiple Routing Services forwarding the original response of a TopicQuery to the application DataReader, the responses may have been erroneously marked as incomplete most of the time.

[RTI Issue ID ROUTING-1227]

14.4.3. Dynamic Data

14.4.3.1. [Major] Routing Service did not work with empty structs

Routing Service could have failed to route a type defined as an empty struct. This problem was caused by issue CORE-14606 (described in What’s Fixed in 7.3.1 in the Core Libraries Release Notes), which has been fixed.

This issue could have caused Routing Service to fail with the following error:

DDS_DynamicData2_allocateMembers: Could not reserve buffer of 0 bytes for values.

[RTI Issue ID ROUTING-1203]

14.4.4. Crashes

14.4.4.1. [Critical] Possible crash if trying to allocate with insufficient memory

If the host system didn’t have enough memory available for Routing Service to allocate some of its resources, Routing Service could have crashed after failing to perform the allocation.

[RTI Issue ID ROUTING-1266]

14.4.4.2. [Critical] Possible crash if custom transformation on input returned the provided input samples or sample infos as output

Routing Service could have crashed or had a memory corruption when using a custom Transformation on an input that returned the same array of samples or SampleInfos provided to it as outputs within its transform() method.

For example, the following code returned the collection of info objects, inInfoList as the output list, outInfoLst.

void MyCustomTransformation_transform(
        RTI_RoutingServiceTransformation transformation,
        RTI_RoutingServiceSample **outSampleList,
        RTI_RoutingServiceSampleInfo **outInfoList,
        int *outCount,
        RTI_RoutingServiceSample *inSampleList,
        RTI_RoutingServiceSampleInfo *inInfoList,
        int inCount,
        RTI_RoutingServiceEnvironment * env)
{
    // ...

    *outCount = inCount;
    *outInfoList = inInfoList;

    // ...
}

This could have resulted in a memory corruption, crash, or just failure to route the samples. Routing Service now prints the following error messages when this condition is detected:

[/routing_services/RsTransformation/domain_routes/DomainRoute1/sessions/Session/routes/MyData/inputs/Input1] ROUTERStreamReader_readOrTakeI:!sample info list: transformation cannot return input sample info list as output; stream name=Example MyData
(...)

Implementers of the Transformation API should manage their own memory in their code, including the allocation and freeing of returned output arrays. The return_loan() function will be called to signal that any allocated memory provided as outputs can be freed.

[RTI Issue ID ROUTING-1236]

14.4.4.3. [Critical] Routing Service could crash if trying to allocate with insufficient memory

If the host system didn’t have enough memory available for Routing Service to allocate some of its resources, Routing Service could crash after failing to perform the allocation.

[RTI Issue ID ROUTING-1207]

14.4.4.4. [Major] Routing Service did not shutdown gracefully when configuration file did not exist

If Routing Service did not detect an XML configuration, it crashed during shutdown.

[RTI Issue ID ROUTING-1332]

14.4.5. Memory Leaks/Growth

14.4.5.1. [Critical] Memory leaks and errors when using DDS-fragmentation with compression or encryption *

Using DDS-fragmentation along with compression or encryption caused a memory leak. This occurred when storing the serialized data from samples received by Routing Service. Errors similar to the following were printed:

FATAL rCo79661##01Rcv [PARSE MESSAGE|0x01016350,0x5A66C0E7,0x8DA940ED:0x80000004{Entity=DR,MessageKind=DATA_FRAG}|RECEIVE FROM 0x01018673,0xDB0C9361,0xB2B4181F:0x80000003] Mx02:/home/user/osapi.1.0/srcC/memory/heap.c:1104:RTI0x2022004:inconsistent free/alloc: block id 0 being freed with "RTIOsapiHeap_allocateBufferAligned" and was allocated with "RTIOsapiHeap_unknownFunction"

[RTI Issue ID ROUTING-1258]

14.4.5.2. [Minor] Memory leak if malformed configuration file prevents Routing Service creation

Suppose Routing Service attempts to use an XML configuration file that is malformed because of a missing closing quote in the xmlns attribute. For example:

xmlns=<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance>

Routing Service creation correctly fails with an error message containing RTIXMLUTILSParser_parseFile. However, in releases 6.0.0 and above, Routing Service also incorrectly leaked memory in the same function, RTIXMLUTILSParser_parseFile.

[RTI Issue ID ROUTING-1324]

14.4.6. Data Corruption

14.4.6.1. [Critical] Routing Service did not perform compatibility checks on routed types

Routing Service may discover types on different ends of a TopicRoute that are not assignable from one another. However, the service did not check for this case when assigning the types to the different ports, which could have caused data corruption or undefined behavior.

[RTI Issue ID ROUTING-1142]

14.4.7. Vulnerabilities

The following vulnerabilities are fixed in this release.

See also RTI Connext Security Bulletins and Advisories for a complete list of vulnerabilities in RTI releases that have been published through the CVE® Program. That list may be more up-to-date.

14.4.7.1. [Critical] Potential stack corruption in Routing Service when using a malicious XML configuration document

An out-of-bounds write on the stack in Routing Service could have occurred after loading a malicious XML QoS document.

14.4.7.1.1. User Impact without Security

A vulnerability in Routing Service while loading configurations via XML could have resulted in the following:

14.4.7.1.2. User Impact with Security

A vulnerability in Routing Service while loading configurations via XML could have resulted in the following:

[RTI Issue ID ROUTING-1257]

14.4.7.2. [Critical] Potential stack buffer write overflow in Routing Service when parsing malicious XML types document

An out-of-bounds write on the stack in Routing Service could have occurred while parsing a malicious XML types document.

14.4.7.2.1. User Impact without Security

A vulnerability in Routing Service loading types via XML could have resulted in the following:

  • Stack buffer overflow while parsing a malicious XML types document.

  • Exploitable by changing an XML configuration file on the file system.

  • Potential impact on the integrity of Routing Service.

  • Potential crash in Routing Service.

  • In Routing Service, the vulnerability could potentially be triggered through the remote administration command load.

  • CVSS v3.1 Base Score: 9.1 CRITICAL

  • CVSS v3.1 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

  • CVSS v4.0 Base Score: 8.3 HIGH

  • CVSS v4.0 Vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N

14.4.7.2.2. User Impact with Security

A vulnerability in Routing Service loading types via XML could have resulted in the following:

[RTI Issue ID ROUTING-1238]

14.4.7.3. [Critical] Potential stack buffer overflow in Routing Service when discovering types or loading XML types with certain characteristics

The stack could have been corrupted when Routing Service discovered a malicious type or loaded a malicious XML type.

14.4.7.3.1. User Impact without Security

This vulnerability could cause the following in Routing Service:

14.4.7.3.2. User Impact with Security

This vulnerability could cause the following in Routing Service:

[RTI Issue ID ROUTING-1235]

14.4.7.4. [Critical] Potential stack overflow in Routing Service when using XML configuration file referencing environment variables

An out-of-bounds write on the stack in Routing Service could have occurred while parsing XML files containing references to external environment variables.

14.4.7.4.1. User Impact without Security

A vulnerability in Routing Service could have resulted in the following:

14.4.7.4.2. User Impact with Security

A vulnerability in Routing Service could have resulted in the following:

  • Stack buffer overflow when parsing a malicious XML file.

  • Exploitable by providing malicious XML code to the applications during startup.

  • A Governance Document that has a value other than NONE for a *_protection_kind that applies to the Routing Service’s remote administration topics would defend against any attacks over the network.

  • CVSS v3.1 Base Score: 6.1 MEDIUM

  • CVSS v3.1 Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L

  • CVSS v4.0 Base Score: 6.9 MEDIUM

  • CVSS v4.0 Vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N

[RTI Issue ID ROUTING-1223]

14.4.8. Other

14.4.8.1. [Critical] Routing Service didn’t allow configuration of its internal clock

Routing Service lacked the ability to configure its internal clock, causing it to malfunction in jump-time scenarios. To address this, a new XML tag, <internal_clock>, has been introduced, allowing you to specify a comma-delimited list of preferred clock sources: “realtime,” “system,” or “monotonic.” Clock configuration is also available via the command-line option -internalClock and within Service Properties, with these methods taking precedence over the XML tag.

[RTI Issue ID ROUTING-1299]

14.4.8.2. [Major] Support for Monitoring Library 2.0 incorrectly described in 7.3.0 *

In release 7.3.0, the Support for Monitoring Library 2.0 new feature in the Routing Service Release Notes (in the “Whats New in 7.2.0” section) incorrectly mentioned that Monitoring Library 2.0 can be enabled programmatically using the RTI_Monitoring_enable_with_property and RTI_Monitoring_disable methods. These methods are not available to customers. The release notes in 7.3.0.7-and-above installations have been corrected to remove this statement. You should enable the library using the participant_factory_qos in XML, as now shown in What’s New in 7.2.0.

[RTI Issue ID MONITOR-695]

14.4.8.3. [Minor] Routing Service user library required inclusion in correct environment variable to be loaded

Previously, it was necessary for the Routing Service user library to be added to the LD_LIBRARY_PATH on Linux systems, DYLD_LIBRARY_PATH on macOS systems, or PATH on Windows systems. Additionally, it was necessary to ensure that the XML configuration specified only the library’s name, not its full DLL path. This issue has been addressed, and the user library no longer requires an environment variable to load correctly.

[RTI Issue ID ROUTING-1314]



* This bug did not affect you if you are upgrading from 6.1.x or earlier.